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' NAMING AND PROTECTION IN EXTENDIBLE OPERATING SYSTEMS 


David Day Redell 


stract 

The properties of capability-based extendible operating systems 
are described, and various aspects of such systems are discussed, 
with emphasis on the conflict between free distribution of access 
privileges and later revocation of those privileges. The discussion 
culminates in a set of goals for a new capability scheme. 

A new design is then proposed, which provides both type exten- 
sion and reyocation through the definition of generalized sealing 
of capabilities. The implementation of this design is discussed 
in sufficient detail to demonstrate that it would be workable and 
acceptably economical. hens a 

The utility of the proposed capability mechanism is demon- 
strated by describing two facilities implenentable in terms of it. 
_ These are: (a) revocable parameters for calls between mutually 
suspicious siheveteas. and (b) dincaties providing a civilized 


medium for the storage and distribution of revocable capabilities. 
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Chapter 1 


Introduction _ 


1.1 Overview 

' Computers have been with us now for just over a quarter of a 
century. Although their ultimate potential impact on society is 
still hard to predict, it seems safe to say that they will rank 
with such transforming inventions as the printing press and tele- 
vision in their effect not only on the way we'live, but also’ on 


the way we think. Already their role has shifted from that of 


simply high speed calculating tools to a more fundamental function 


as the natural ‘repository for an 1icreading “ssount’ of deciéety's 

body of information. The near future should’ see ‘the development 
of computer utilities bringing reliable and economical computer 

access to the general public, in the’ form of services of unpre- 

cedented scope and power [Fr 74]. : 

These new roles of computers raise many serious social ques- 
tions which are far from being answered [Ro 74, DF 65, HEW 73]. 
Moreover, even if these questions are satisfactorily answered, the 
resulting policies will require an appropriate technological frame- 
work within which they can be expressed and enforced [Po 74, Pe 74].. 
Thus, such social and legal issues as privacy, secrecy, confiden- 
tiality, and accountability generate a technological problem which 
could be called the "total system security problem.” 

The main subject of this thesia is protection. Protection is 
that aspect of the total system security problem which deals with 


the control of access by programs running within a computer system 


to information stored within the system {La 71, Jo 73]. It is thus 
concerned with prevention of undesired accesses, whether accidental 
or malicious. Protection is intimately involved with the naming 

_ mechanisms used by programs to specify which items of inféoveneton 
they wish to access. . We will diacuss gystem designe which provide 
both naming and protection in a single dategrated mechaniam [DVH 66, 
Fa 74]. We also emphasize the notion of freely : 


ely distributable 
access privileges, in the sense that any possessor, of a privilege 
may pass it on as he seea fit [La 69]. On the other hand, we recog- 
nize the importance of allowing later reyocatign of auch privileges. 
The main result, of the thesis is the description of a naming and 


protection mechaniem allowing both free digtribs 


oa of privileges 


and subsequent, revocation in an orderly WAY. ; 


Es 


_ Another desixable . characteristic of naming and protection 


ef tee FS 


mechanisms is extendibility [La 6%, Wa 741, This, property allows 
the constryction of the systen ip layers or "leyele of abstraction” 
[Di 68b], thos increasing reliability, and allowing, user-written 
extensiona to augment the sygtem with new services in a uniform 


way. The extendibility of the proposed mechs 


deme will be discussed 


in some detail. 


dg 


‘1.2 Protection - be ae Si hey Seti a: 

The protection problem is only ope agpact of tpe tetal system 
security problem. : Thus, in discugsing fhe protection problem, it 
is important to delimit the scope of the digcuaaian, by, distinguish 
ing several other closely related problems, including: 


a) 
_b) 
c) 
D. 


Hardware reliability. 


_..Physical security 


User authentication 


Pergonnel certifigation. 


All of the above problems exhibit two rather unfortunate properties: 


2. 


They do not admit of complete solutions, but.only of solu- 
ions quantitatively comparable in terms.of cost-effective 


‘Prevention of trouble (e.g. high penetratian cost, long 


_ Mean-time-between-failures, etc.) . 


(‘The failure of a solution to, any gpe of them.can under- 


ming the entire protection ayatem, -... 


On the other hand, if we hypothesize a situation in which problems 


(a) through (d) have been completely solved, we can consider the 


protection problem as occurring in a self-contained artificial 


universe, free of such real~wor]d distractions 48,.30cks which can 


_be picked and circuits which can burn out. Within this idealized 


framework, the protection problem-dogs admit of complete solutions 


in many important situatians [La.74]. Thig is not to say, of 


are automatically complete. For. example, one can protect data by 


requiring accessing programs to provide a password or key authorizing 


the access [La 69]. Internal paseworda, like external passwords, 


are vulnerable to guessing, and are thus. not. a complete solution. 


On the other hand, one can implement internal keya which are 
_unforgeable, opening locks which. are unpickable, thus providing 


a complete solution to the problem. The significance of this lies 


not primarily in the reduction of the. probability of failure (from 


negligible to dave) but in the conceptual shift in how one views 
the mechanism (with absolute confidence, rather than quantitative 
optimism). 

It can be argued that the above viewpoint is imréalistic, 
since problems (a) through (d) do not admit of complete solutions 
as hypothest#ed. The point, however, is that this factorization 
of the total security problem allows one to take a very ene 
approach to the situation in which malicious intent manifests 
itself in the behavior of high speed internal computations. This 
is precisely the situation in which our intuitions are least likely 
to prove reliable in assessing the quantitative adequacy of incom- 


plete solutions. 


1.3 Pramework for Discussion 

For our purposes, we can regard the function of the operating 
system as being the transformation of the basic hardware resources 
of the computer into a universe of abstract resources or objects, 
and a set of operations for manipulating those objects. This point 


of view is often referred to as the obfect 


~orfented approach, and 
the collection of operations as the abstract machine. ‘Each object 
has an attribute called its type, which determines the set of 
operations which can meaningfully be applied to the object. Various 
types of objects are provided, most notably processed. Processes 
are the active entities in the system, capturing the ihtuitive , 
notion of a “locus of control" or "execution pofnt ." Processes 


can attempt to access other objects in the system by performing 


various operations on \ them, . and it is. these accesses which are 


checked and allowed or disallowed by the protection mechanisms of 
the systen. Ac ay. given time, a process, has game set, of privileges, 
specifying hich Operations. it may perform . pn which gbjects. This 
set of vet iteees da called the domain 1 in Mbich ¢ the process is 
etecuting: The privileges available to.a process can change as a 
result of either: 
a) addition or removal of Privileges, 4 in ite domain, of 


. Executied, Or ee ne 
b) eer renens. to. a different domain, of execution. 
Thus, domains chemselyes have an independent existence, and are 
objects = their own Fight. the. reasons, for taking, this. point of 
view s will become clear in Chapter 2. “2d. A domain. can be. ,characterized 
“as a passive object, serving to control, the execution | of an active 
“Process. 1 mee Pieler ornen be convenient, however, to refer to the 
actions oF a aprocess executing in a domain. as being. performed by 
the domain iteelt, and we will use. this active characterization 
when there is. no © danger of ambiguity. 
- . The domain = a8 general enough . to Seserihe. most protection 
“schenes £ found in existing eysteme [La 71). _We are interested in 
a particular, class of ouch schemeg. An which a domain consists of 


a | set of es 


abilities [DVH 66, La 69... Fa 74). A Sapability serves 


both as ‘the name of an object and. as 3 set. of Betvileges | to access 


ans 


Pe: 


that object. ‘Thus, in a ‘capability eysten, a domain is able to 
name only those objects to which jt has access via its. capabilities. 
Those eupapit ities are stored in. the memory, of he domain, which 


z 


we will assume consists of a number of segpents [De 65, BCD 72], 


AEG on tee laf ac eRe geE iT t eet or re za © 


each of which comprises a variable length array of addressable | 

items. A domain may copy its capabilities and distribute them as 
it sees fit, although it may not, of course, nike arbitrary modi- 
fications to them. ‘Thus, capabilities are Like Pere "sealed ina 


box,” a chavketavisetion which we will pursue in some detail later. 


1.4 The Computer Utility 
The mechaniems discussed in this thesis would be useful in 


any computer system. The context which maximizes their importance, 


however, is that of the computer utility. The notion of a computer 


utility has received considerable attention in the literature [CV 65, 


Sa 66, Sc 72, Fr 74] ana eekan likely to play an increasingly | 
important role in the future. In such a utdlicy, a iacge user 
community shates an appropriately large information storage and 
processing facility in much the same manner that the users of elec- 
trical and ‘telephone utilities share the cocresbonsing power genera- 
tion and communication facilities. Such physical sharing (1.e., 
sharing of physical resources) provided the original motive for, 
developing multi-user computer systems. That motive was the desire 
to lower the cost of hardware resources through economies of scale 
and statistical smoothing of toad fluctuations.’ This is gradually 
being rendered less important by the continual dectine in hardware 
costs. A much more fundamental motive remains, however , which is 
in itself more than adequate justification for buiiding a computer 
utility. This is the desire for flexible logical sharing (sharing 


of information) between users, so that they may build upon each 


other’ s _ work {Sa 66, _De 68]. 
Since the user community of a computer utility sgndate of the 
public at large, the logical sharing within that community takes 
on more the character of transactions in a-marketplace than of 
informal friendly cooperation [Fr 74]. In particular: 
a) Sharing is often financially motivated. — ; 
.») _The parties involved may not trust each, other. 


Point (a) implies that, sharing often represents sale, or rental of 


the shared objects. The rental case is a strong test of the pro- 


tection and Srecunting mechanism of the comppter, utjlity. This is 


particularly true in the case of —soblepeing, dn. which access. to a 


Tented object passes through several, hands, before. reaching the end 


"ser. Foint (b), which 1e in part « repult pf, (a),, reflects. che 


fact that the standard attitude of the parties, involved in a trans- 
action in any market place is usually some degree of wutual suspi- 


clon. Since programs in the system perve ag. the agents of jsers 


on the outside, the programs themselves aleo exhibit mutual suspi- 
cion. More detailed discusgion and examples of mutual. suspicion 


can be found in Lampson [La 69] and Schroeder [Sc 72]. 


One aspect of the mutual suspicion problem which can be awk- 
ward to handle is the fact that the degree of suspicion between two 


users may change with time. For example, gn employee may, join or 


pOnve, 8 COMPANY, or a renter may be late in paying his bill. Thus, 


1. is amporrane chee he privileges of a given user or program to 


aytae 


access a given object be able to change with time, Moreover, it 
_ tt very desirable thet these edjugtments of privilegne be ae pein- 


less as possible. We will address this iggug at, some length, 


particularly in the case of increasing suspicion where previously 


granted privileges are to be revoked. 


1.5 Extendibitlity 

The construction of a large operating system is a formidable — 
task. As the richness of the user environment provided ie incréased, 
so also is the size and complexity of the systen which provides it. 
In fact, unless controlled by a suitable design methodology, the 
complexity of a large operating system nay preclude its ever being 
completely debugged. One of the most promising such each doiveies 
‘is that of layering, in which the system is constructed as a base- 
“leve1* and @ series of extensione. Kach layer extends the environ- 
ment in whith it runs, thus presenting a richer environment for 
higher layers. The key assumption in such a system is that no layer 
has embedded in it any knowledge of the functioning of higher 
layers. This, combined with the obvious precaution of protecting 
lower layers from itrference by higher layers, yields a structure 
in which changes to and malfunctions of higher layers cannot affect 
the correct functioning of lower layers in any way. 

The construction of a layered system can be viewed in two ways. 
From a top~tiown point of view, the task is one of appropriately 
dividing the desired set of functions into a sequence of ‘layers. 
From 4 bottom-up point of view, the ‘task is to ‘transfors some pre- 
existing systen into a more complete environment. by" adding useful 


new features. The latter point of view ‘te most sppropriate in the 


"Sometimes called the "kernel" [Wu 74] or "nucleus" {Ha, 70]. 


a in 


case of user-written extensions, although to a large extent, the 
EUS A! fe 


Faeee Sseesaictise betrees a7 stem Oreste Gnd eer, J igrene Decunes 
beter aun ae 5, dayered design. was sah Bar a. oe 
eon Cre eres ee ee ee eee 
appropriate way to view extensions 18 aa gefining nev types of 
objects and providing the appropriate operations on, then. This 
mediately raises the question of how auch objects are named end 
how access to them is controlled, It is most desirable for the base-~ 
level naming and protection mechanisms to provide these functions 


for all higher level objects in the system. We will describe 


various type extension features which allow this. 


1.6 Thesis Plan 

Since. the mechanisee described in this cheuis caucesunt fur- 
ther developments of ideas found in several existing or proposed 
computer systems, it is appropriate to summarize those ideas. 
Therefore, Chapter 2 begins by describing a hypothetical system 
exemplifying the relevant features of those systems, and goes on 
to discuss the use of those features in various attdetioue: placing 
special emphasis on revocation of privileges and on type extension. 
The chapter concludes with a list of goals derived from these 
discussions. 

The eentral portion of the thesis is Chapter 3, which proposes 
a new system design satisfying the goals derived in Chapter 2, and 
discusses the implementation of that design in some detail. Some 


possibilities for further elaboration of the design are also 


10 


discussed briefly. 

Chapter 4 examines the use of the mechanisms of Chapter 3 in 
providing two facilities helpful in common situations: revocable 
parameters for mutually suspicious subsystem calls, and directories, 
for storage and distribution of capabilities. 

Finally, Chapter 5 summarizes the results of the thesis and 


briefly evaluates their significance. 


are applicable. 


2.1 A Typical Capability System os 
The central goal of this theais is the detatiad specification 


of a . proposed behavior for capabilities, and che description Be an 
efficient implementation of capabilities exhibiting auch behavior. 
The main aspects of capability behavior to be examined are the 
distribution and revocation of privileges, and type extension. To 
bring the issues into pocua: we sketch a ‘hypothetical system called 


"Ts" “(for yeteat Capability syeten") ‘to serve as a context for 


‘discussion and as a starting point from which various mprovenents 


can be explored. ‘This typical system : as described ‘halow is not 
identical to any existing or proposed system “but contains features. 
found in many previous systems, including CAL TSS {La 69, St 73], 
Magnum [Fa 68], Plessy 250 [En 72, “Co 721, HYDRA [Jo 73, Wu 74], 
Project SUE er 7, BCC 500 [La 691, and Multics (aco 72, CV 65, 
Sa 74]. “a 

In the definition of TCS, two cout ict ing Considerat lone 
influence the level of detail at ich ecu tous features should 


be described. On the one hand, it is Amportant that the cb tind ison 


be specific enough ‘to make subsequent ‘tecuasions clear ‘and unam- 


biguous. On the ‘other hand, the tnclosios of. ‘extraneous detail 


would not only cloud the issue, but might also ‘faleely appear to 


restrict the class of systems to which our subsequent Amprovewents 


at 


_ For these reasons, the definition, that. follows tends to pin 


12 


down only those details which are relevant to the later discussion. 
In other cases, several alternatives may. be sketched, or the fine 
points may be glossed over entirely when not sufficiently 
SREGE OREN: | 

In defining TCS, a logical piace to begin is with the capa- 
bilities themselves. ‘As stated previousiy a capability serves 
both as the name of an object and asa package of privileges allow~- 
ing the object to be accessed in various ways. It is ales desirable 
to distinguish between objects of different types; in TCS this 
distinction is carried in the capability, rather than in the object 
itself, for reasons which will become clear during the discussion | 
of type extension. — Thus, a capability for an object contains: 


a) the un unique identifier or "iD" of the object 


b) the t type of the object, 

c) a set of privileges to access te object. . 

Each domain in TCS has its own segmented address space. (As 
pointed out by Fabry [Fa 74], freely copyable eapanaitt tes elimi- 
nate the need for communicating comes to share. @ common address 
space.) The capabilities possessed. by a ‘given domnin are stored 
within the seguants of its addreas SEAee: At the: same tine, . those 
capabilities serve as the tisieten which. defines and structures 
that addrese apace. (It is worth euphasizing, that an address space 
defined by freely copyable capabilities tends to be s much tore 
fluid structure than a4 more conventional address space defined by 


system data structures.) Associated with each domain is a single 


“The object ID has sometimes been referred to as the “unique name" 
or "global name" of thé object. We wish to evoid this terminology 
to emphasize the fact that it is the capability itself which — 
should be thought of as the global name of the eniect 


__. devel addresses and/or programmable 


implicit segment , which serves as the "root" of jts address space.” 
A capability for the implicit segment is part.of the definition of 
the domain. All other segments (or objects of other types) are 
addressed via capabilities in this implicit gegment. ‘There is no 
fundamental reason, however, to restrict capabilities tq appear 
‘only in this implicit. segment; in fact, it will be assumed here 

_ that capabilities and "normal" data can be freely intermixed in 

any segment. (ways of implementing this without compromising the 
integrity of the capabilities will be discussed later.) 

Outside the context of any particular address space, we can 
define the absolute address of an item (capability or datum) to be 
a pair <C,d>, where C is a capability (for a segment) and 4d 
is a displacenent (word, byte, or bit number). Let. (C,d). denote ° 
the contents of address <C,d>. Then if c, is a capability for 
some domain's implicit segment, a simple addrees w iagued by 
that domain corresponds to the abaglute addreas. <C,,w> (h.e., 
| word w of the implicit segment). Similarly, the standard notion 
of the two part address s|w of word w in segment 8 is equi- 
valent to <(C,,8),w>, When capabilities can be stored anywhere 
in the address space, addresges involving them can become more com- 
plicated, such as s|w,|w, =, <(({C,,8),w,)w,? (where both <C,,8> 
and <(C,,s),w,> must contain segment capabilities). This. suggests 


the provision of direct hardware implementation of these multi- 


Lary restecers fo. bold 


eee ts 


“this is similar to the Multics deesriphor, segment [Bi ae or the 
‘CAL-TS8 working C-list [St 73]. Tye 68° 

Plessy 250 [En 72] machines, it is a ieeesrsit i pak oe in hard- 
ware in the form of several capability registers. Lampson [La 74] 
refers to the implicit segment aa the "access point" of the domain. 


14 


Antermediate capabilitiés duting the evaluation of such addresses. 
Lacking these features, a domain could diréctly utilize only 
capabilities in ite Laplictt aégmétit; all other capabilities would 
have to be copied into the implicit segaent béfore use. Various 
forms of multi~level addressing have been provided in ‘existing 
systems [Ha 72, St 73, Ne 72, wa YA}. | 

Figure 2.1-1 depicts two domsfns D, and D,, whose implicit 
segments are $, and 8, respectively. The address space of D, 
includes segments 85> Sas Ss, arid S.. The ‘address space of D, 
> 85> Se,’ and Sy. ‘Note that 8, 
shared by both domains, and that the address space of D, may in 


includes 85, s and S, are 
fact include (indirectly) the entire address space of ‘Dy, depend- 
“ing upon the privileges in D,'s capability for 5,. my 

. As mentioned in Chapter 1, domains can be ‘Characterized as | 
either active or passive objects. “In its passive role as a collec- 
tion of privileges, a domain in our typical capability fair is 
identfeal to its implicit segment; from this point of view, the 
distinction between a domain and a segment is siaply a question of 
emphasis. On the other hand, in its active tole anan exerciser 
of privileges, a domain is sure to require additional information 
in its representation, relating to control structures, error handling, 
entry points and so on, witch we will call ita: domein-descriptor. 
While the exact details of this extra information ate “not relevant 
to the current discussion, it will sometines be useful to dietin- 
guish between the domain in this laiger sense, and its implicit 


segment. 
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Figure 2.1-1: An example of two domains 
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The active characterization of domains is somewhat imprecise, 
since, strictly speaking, nothing is ever done by a domain but 
always by a process executing in or associated with the domain. 
This raises the issue of the exact relationship between domains and 
processes.* Since protection and scheduling are essentially inde- 
pendent fuactions, it is tempting to define domains and processes 
independently, and to allow processes (at least potantialty) com 


plete freedom to choose their domaia of execgtien. This implies 


: vm 
Fen vere F 


that 

a) A given process nay execute in various domains at 

different times. 

b) A given domain may have AaEOs DEE CF several processes 
| executing in it at any siven: time. 
‘In such a schame , two types of conmuni.cat Son mechanisns are required. 
One is interprocess communication, which allows two parallel pro- 
cesses, in the same or different domains, ito eynchronize their 
execution and exchange messages. the othec is interdomain 
commmication, which occurs at the point in time when a process 
ctosses from one dosain into another. This is generally viewed as 
being much like a procedure call/return sasuenca, Jacluting the 
passing of parameters, and is thus referred to as a domain-call. 
This will be discussed in more detail later. 

In actual systems, one or both of two simplifying restrictions 
is often imposed. The first restriction is to force a given process 
to always execute in the same domain. This eliminates the rather 


complex machinery needed for domain-calls, and forces all 


* : 
Called "environment binding" by Jones [Jo 73]. 
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inter-domain communication to be cast as inter-process communication. 
While this is clearly a simplification’ of the base-level system, 


in practive it often forces higher “level software to essentially 


‘eimulate’ domsin-calls using multiple processes, only one of which 


is active at any given time. This is wot érly ‘ineffictent, but can 


also. be surprisingly clunsy, considéring that parallel processes: ‘ 


seem to be such a powerful construct. Indeed, the unused potential 


- parallelism seems to cause much of the clumsiness. - 


The other restriction which is often applied is to allow only 


one process at a tine to execute ina given dotiain. ‘This can be 


done dynamically, treating the domaiti as a “critical section,” but 


is'more often dome statically, by associating each: domain with a 
single process, and allowing only that: process to execute in it. 

Gnu eagen for making this restriction is the previously mentioned 
correspondence batueen demnine and address spaces. As pointed out 
by: Lampson’ [La 69] this tends to result in-ddd¥ess conflicts between 
multiple processes executing in thé’ same domain: Oné way to avoid 
these conflicts is to equip each process with special base registers, 
or a pushdown stack £62 working storage, but what such mechanisms 
really provide is simply ‘the ability for éach of the processes 
executing in a given domain to see the domain somewhat differently, 
in..a rather stylized way; A more straightforward and flexible 
approach.is to actually provide a different “copy” of ‘the domain 

for each process, and to use the standard sharing mechanisms to 


avoid redundant storage of the identical ¢compdnents of these domains, 
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(e.g. pure procedures, unchanging capebiilities, ete.).*. In such a 
| scheme, each process has a private set af domaina, and mowes among 
them using the domain-call mechanism... Such.a sghema will, be assumed 
in subsequent. discussions of TCS, although thie is mot essential 
to the proper. functioning of the improved capehi itty mechaniams 
proposed later. | 

Given that a domain possesses. soma, capability, it is allawed 
not only to use the capability to accese the indiceted object, but 
also to. manipulate the capability iteelf, in. ceztadn carefully 
constrained: mye including: 

a) Copying: the capability may bq freely copied et any: time, 

here denoted. by. a. simple asaignment. 


otc, 


b) Reduc rivileges: the privileges in. the © capability 


aay be reduced, here denoted by: a Pain, 
reduce(C, ,P) 


where P iz a mask indicating the: subset. of Cte 
previous privileges which ara. te be -entained. 3 
In. some ayatems. [St 73] theae two. operations-have been. combined ; 
here, they are presented separately tq ease the abe: rr eal 
to an. improved scheme. 
One use of tha mechgnions described ao far would be ithe 


"We will assume that a domain is created by an explicit create- 
domain operation, and remains in existence until destroyed: [St 73]. 
A more complicated approach provides the automatic creation of a 
domain whenever a call is directed to a global domain-ptototype | 
object (Wu 74]. 
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passing of capabilities between domains via shared segments. In 
one sense, this is a very powerful feature, since it allows any 
possessor of a privilege to ne ee without requiring any sort 
of approval by the original donor of that privilege (except in the 
special case in which the donor is empowered to disallow all such 
“sharing; e.g. in the case of | a "confined" subeyaten [La 73]). In 
“another” sense, however, this feature is very weak, ‘gince it pro- 
vides’ only a ‘relatively costly, clumsy ‘aaa unstructured method of 
inter-domain ‘communication. This Venicese would be particularly 
evident in the case of mistrust between domaine (e. g. “mutually 
suspicious" subsystems). Both of these ‘considerations suggest that 
the domain-call mechan lan should provide for the passing of. capa- 
bilities, as well as data, as 5S uacamstere. The latter consideration 
suggests ‘the utility of such a feature, while ‘the former gnaw 
that the ability to keep a domaia from giving away its privileges 
is already eliminated by freely copyable capabilities and is not 
further compromised by allowing ‘the paneiee ‘of capabilities as 
parameters. 

We assume that TCS allows the passing of capability ot 
‘and implements this by eesying the indicated capabilities from the 
calling domain (or caller) to the called domein (or callee) at the 
time of the call, and copying back any result capabilities at the 


* etwe’-Of the vatuca, “A domainscall: thus. takes the form 


call (CoP, Poe. oe »Py: ‘hoe 


where the P, are parameters (data or capabilities) and Cy is 


20 


a gate capability for the callee, allowing activation at.a particular 


entry point. Similarly, a domain-return takes the form. 
return (By sRos «on a) 


where the R, are the resdite and the return gate is implicitly 
the site of the original call. We leave unspecified here auch 
details as static vs. dynamic allocation of space for capability 
parameters in the receiver's address space, automatic type checking 
of capability parameters, and so on. -_ 

. In addition to making unwanted aceesaes to objects, domains 
can misbehave by making Uunreasouable deuande on the resources of the 
system [La 71}. Some mechaniew must be provided to prevent them 
from interfering with each other in this manner. Since Eke details 


of accounting and resource alfocation are beyoud the scope of this 


thesis, we will simply assume that, each. domain is funded by an 


account, which limits its resource ‘consumption. — 

One particularly tricky Scien: whitch occurs in capability — 
systems is the "lost object problem," which arises when all capa- 
bilities for a given object are inadvertantly discarded, making 
duptdete destruction of the object iupossible, and: the space occu~ 
pied che (eerecovereple << Given our attitude about accounting, this 
is really an oppor edntty for self-inflicted harm, | rather than mali- 
cious sabotage. nevertheless: recovery from such situations must 
be possible, hence several possible solutions bathe “lost object. 


problem will be discussed at appropriate points. 


ge 
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2.2 Implementation of fa: abilities in Oe te 


In this pection we discuss, dn. a fair smpunt o detetl, cer- 


tain aspects of the snp eeent ation of a system Like rcs. Three 
conaiderat- tons influence the choice of, , the particular » mechanisms 
described in this gaccicd: For. one thing, various “aystens eimilar 
to TCS have been citer, and their _Amplenentet ions, elehoush 


varying in many ways, pave shove some _fommon features whose advan- 


3 I - ct 


tages have Decome generally accepted, 1 In addition, certain facilities 


not tuctuded in any exter ine capability ayaten are videly regarded 


as desirable, hence ue implenentation implications are of interest. 
3 Wa Fak 2 


Finally, discussion of implementation of TCS is intended to set 


i igdab Lf 4: 


. the stage for the coxreaponding dtecussion in ig seaahere 3 concerning 


the implementation of a more sophisticated ‘capability 9 echene. 


~ most obvious necessity in tap tement iss. a capability agates 


af some mechanion to Protect. oe “representations of phe ee 


themselves from unauthorized alteration. ~ proper “functioning 
of the entire eyaten is. based upon the Antegrity of capabilities, 


hence this mechanism should be simple, to maximize not only. its 


reliability, but also its understandsbility, aad thus, Anspire user 


confidence. Two mechanisms have ‘been Proposed, which | we walt call 
"partitioned memory" and “caged memory. 7 —: . 

All capability oe which have actually been constructed 
have used pares troned memory. As —: name suggests, tI sg schaue 
involves percietoning the eagnente in the 2 aysten ante! ewe yo classes: 
capability segments which contain ony capabilities, and) data seg- 


ments, which never contain re deal pepo aae ont obvious advantage 


‘of this accha eae is that the cost of distinguishing between 
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capabilities and data is distributed over ati entire segment, reduc- 
ing the overhead per iten, put the main advantage of partitioned 
“memory is more subtle; it involves the. wvotdanes of certain address- 
ing complications which arise in the tagged wsmory approach, as we 
shall see shortly. The main disadvantage of partitioned memory is 
‘that the artificial division of a user's mewory into two parts is 
inconvenient. It is often quite natural for information structures 
(e.g. entries in a table) to contain both data and capabilities. 
While Sach intermixing can be similated using a pair of segments, 
this is a fairly clumsy procedure. For thie and other reasons, 
discussed in detail by Fabry [Fa 74], we reject partitioned memory , 
as indicated by our specification of TCS as allowing free inter- 
mixture of capabilities and data in any ecient. | 
The tagged memory approach allows such fatermscure by attach- 

ing one or more extra "tag" bits to each information item in each 
segment. ‘The term "item" is used here to denote the basic address- 
ible unit of memory (word, iykess wees). “These tag bits are unmodi- 
fiable by any software except the most central routine of the base- 
level system. Each item's tag indicates ite status as ‘data’ or 
‘capability.’ An item must be tagged as a capability to ba used 

as one. An item so tagged can be geterated only by copying another 
such item, or by the base-level capability-crestion routine. On 
the other hand, a tagged capability can be acaned by overwriting 
it, either with data ee with another. capability. (The system could 
require that capabilities always be explicitly erased before their 


storage is reused. We reject this as too inconvenient for the user, 
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although there are caseg in which jt would mgke things oglightly 
_, @asder for the eystem.) 0 2, 0k oes stiche te ai Ae 

_ The only proedugtion computers, sbigh. ‘BSA, EQGREA BeMOTY are 
the Burrqughs 85000 [By ,61).and ite degcendagts,” .The protected 
items in these machines are."'deacripaters" skather than gapabilit ies. , 

The differences. between the two:.do. nef: -RORESTR US. gre, except for 
-one; des¢ripters are.considerably;smaller phan capabilities. A 
‘Byrroughs descriptor. is 48..bits Leas, watig..pany .gxtgndible capa~ 
bility, systems, have allowed, in excens of 100 bite -fgpzeach capa- 
‘bility. The dmpact of .thia.will become clear,in a mapent, 

_ While the advantages, of tagged wemgry have keen giqwly..gain— 
- dng acceptance,.apother trend. which, has. had,eyen,more,impact is 
_ the reduction.of the size. of, the addressable ifens.,in memory. 

While machines with items of 36, 48):9%, even, 60. bigs vere .common 

_ dg. the peat, the. byte (8, bit. characrer) 4a. rapidly, becowing. 2 
universal: shanderd, end. strong, exgumente,,cap, be made for, the ulti 
mane xeduction to bit. addressable. pamoxies.... Ip, euch schemes, a 
larger unit of information (es g-® capabijity)..4s, represepted by 


_ @- contiguous sequence of items. apd. named: by the address of its 
 fdrst. item plus ite length. Gmplicit of explicit). in items, 


 hagged memory, da, given..by Feusts 


: ‘There: 4s a very real.confiict. between. these typ features. 
Two. problems aries. when the, reprementation of, a Sagspd. capability 
ig a sequence of addressable items, dn memory.;, Ong, Ja the obvious 
increase. in coat of associating * tae: with epch, item as the, items 
get smaller. The other js. the poaatbsiity Jp eueh_a, scheme, of 
Yartous eoperipental. aohiags hers, jme4 aigemral discasion of 


Le. Jl «, ap ae 


24 


addressing the Widdie of a ‘Gapabiftry. 
_ If we assume that each item has 4 one. bit. tag, we are faced 
with the question of which of the items in « capability should have 
theft tage on (1.¢., set to 'capability'). If afk of ‘thefr tags 
are on, tlre fs no convenient way for the systeu to dist tiguish 
Betwee a valid capability addrees, atid one which pointe to the 
middie of 4 capability. Thée latter ‘case could lead to the recog~ 
nition é6f the last few items of one capability, together with the 
first few iteme of an imbedfiately fotlowing capability, as con- 
stitutihg @ valid capatitifty, henée this asbigaity must be avoided. 
One way of doing this ts to’etrn on onty the cag of the first item 
in #ach capabilicy, and require that the first (and only the first) 
item Located by a capabiiity address be so tagged: ' Tits sakes the | 
other items in a capability iadistingatenad: 


abie from data, however, 
avd leaves them open to alteration unless avery store operation 
scans the tags of the appropriate niumbet of preceding items and 
turns them off to insure invalidation of any capability which con~ 
taife the item(s) being modified, 

It is clear, then, that an address pointing into the middle 
of 4 capability mast be distinguished borh fren a valid capability 
address afd from an address of untagged data. Thi suggests the 
tiéed for two ‘tag bits on wack item, oné indicating whether the | 
item is part of a capability at ali, and the ‘other “Sniicating whe- 
ther it fe the First item of a capability. Bince the second tag 
ia fetessary only when the first one te on, “at cottid be "stolen" 
from the bits of the item only when needed (although ‘this obviously 
doesn't work on a bit-siddressable senory,: saci ‘the. item would then 
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have no bits left at all!). . . a 

The other problem, the high cost of tagging small items, 
exerts a strong pressure to increase the size of items. Arguments 
in favor of small items generally cite the fect chat, for a given 
total bit capacity, address size grows only. logarithmically with 
decreasing item size. Unfortunately, the cost of tagging grows 
linearly, reaching a maximum in the bit-addressable case of ‘we. 
tag bits per eitoreatdon bit, which is clearly out of the question. 

One alternative tagging scheme which we reject allows small 
items but imposes the restriction that capabilities can only be 
stored oe addreases which are an even multiple of the length of a 
capability. In such a scheme, memory, is item-addressable for normal 
Se aii capability addresses must locate ane of the predeter- 
mined "capability frames." Such restrictions tend to complicate 
the software and sacrifice many of the advantages of item- 
addressability. ; » ee 

A much more sophisticated scheme, which also involves the 
notion of a capability frame, atveuee to exploit the fact that 
the assignment of tag bits to each item is a relatively ineffi- 
sudent encoding of the set of possible data/capability configura- 


tions in a given region of memory. Even if capabilities can begin 


at any address, the number of different artahgements in a given 
capability frame is not large: At ‘post one dibability can begin 
in a frame, and can be preceded by one or more data items and/or 
the trailing items of a capability which began in the previous 
frame. By associating with each frame the integer displacement of 


the capability, 1f afy, beginning inthe frame, it 1s possible to 
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simulate two bit tagging of each item. This is a somewhat compli- 
cated approach, but may evéntually prove to be the key to bit- 
addressable tagged memories, since it allows the cost of tagging, 
like that of addressing, to grow only logarithmically with decreas- 
ing item size. This scheme also has the rather intriguing property 
that reducing the size of capabilities does not always increase the 
efficiency of memory utilization. Yor a given pattern of ‘eked; 
there is an optimum size for capabilities, such that deviation in 
either direction increases the total overhead for capability 
storage.* No existing system uses such eheae. mithoogh it has 
been tentatively investigated by Gray [Gr 73). 

We thus conclude that our 4mplementat ion of TCS should use one 

of three tagged memory schemes: ee | 

a) Items should be single bits, and the scheme just described 
should be used to simulate two bit tagging. 

b) Items should be a substantial fraction of the size of a 
capability, allowing a two bit tag per item at a reasonable 
cost. . | os 

c) Items should be large enough to hold an entire capability, 


allowing a simple one bit tag per item. 


*ssoune, for eXample, a bit addressable mémory in which the average 
_ object is N bits long and ip pointed fo by k. capabilities. 
Then the overhead for capability storage is the fraction of memory 
taken up by ‘tage. plus the fraction holding ibe -sepgbtlities thea- 
selves. As a function of the size ¢ of capabilities, this is 
ct+log c + WHke ° 
For instance, if N= 105 bits and k= 10, the storage of 64 bit 
capabilities requires about 15% of wamory, while reduction to 32 
bits or expansion to 128 bits increases the overhead to about 172, 
and 16 bit or 256 bit capabilities sequire gbout. 22%... 


F(c) = 
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To ateeltty subsequent discussions, we adopt ey eernat ave (ec), 
eiebougs it would probably not be feasible for res. as described, 
since capabilities are so large. In Chapter 3, “however, we will 
describe a scheme in which capabilities Fit ints more reasonable 
sized tagged items. 

The second major Auplenentation aspect to be discussed is the 
nechanisa for mapping the ue found dn capabilities 1 into physical 
addresses of objects. The most obvious cae tmate would ‘be to simply 
_use the physica? adcess as the D, but that, vould imply updating 
all the capabilities for an object wtsnever 36 was mores or deleted. 
This is impractical dus to the proliferation alloved by free copy- 
ability, especially ina cayeten echoes intermixing « of capabilictes 
and data in pOements: 

Most eapabiltry systems have solved oe problen by localiz- 
ing changed ie antorest toa about objects in a 4 system data structure 
and SORCINE all access to the object vie capabilities to Be indi - 
rect ty: through this structure, which has been referred to by such 
terms as “Master Object Table" [st 73, “system Capability Table" 
{En 72], and "Global Symbol Table" Tw 74), Here, we wit). rétex 
to it as simply "the map." 

There a one-to-one perresponcence porwr. | objects and 
entries in the 2 map. An ebiece. and its map entry | are created and 
ddstroved cogether: Since the capabilities for an ‘object are not 
updated when it is destroyed, it is not ‘satisfactory to use the 
location of an object's 8 } entry in a the mer as its ID, since that 


would prevent re-use of map space freed by object destruction. In, 


fact, the ID of a destroyed object must clearly never be re-used, 
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since capabilities for the old object aula Ped be aed to access 
the new one. This suggests that IDs should be quite long, so that 
the apace of IDs can never be exhausted, evan: if objects are created 
and destroyed at the maximum siseible ate foe the entire life of 
the system. The alternative of occasionally stopping the system 
and compacting the space of IDs is plausible, but eas eteractive: 
Any generator of a sequence of unique long integers can be the 
source of IDs. A counter of the total duebar of objects created, 
or a real-tine clock of sufficient length and resolution are the 
common cagep ten: In either case, provision must be made ae 
restarting the system after a failure without any possibility of 
repeating a previously used ID. | | 7 
As a first approximation, we can consider the map translating 
such IDs into. physical addresses ae being iuplenented ss a large 
hash table da grimasy wanorys keyed on IDs. Figure 2.21 shows 
the representation of capabilities and map entries. (The field 
labeled "address" is assumed to contain any extra information 
necessary to distinguish between primary and secondary storage 
addresses. The details are not relevant here.) Each mee of 
a capability involves: | 
. 1) checking the appropriateness of the action, given the 
type and privileges in the capability (and signalling 
an error otherwise), . Te 
2) hashing Lito the map to verify the existence of the map 
entry, and hence the corresponding object (and signalling 


an error otherwise), 
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object ID 


capability: 


object ID 


Figure 2.2-1: Format of capabilities 
and map entries in TCS 


map entry: 
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3) checking the address in the map entry for the presence 

of the object in primary memory (and signalling an excep- 
tion otherwise), 

4) using the address to perform the access to the object. 
These steps are simple enough to be implemented in hardware or 
firmware, and would be used heavily enough to. cad such imple- 
mentation. 

As déscribed so far, the mechaniem does not deal adequately 
with the two extreme cases of objects which are accessed very fre- 
quently, and those which are screenees very infrequently. Objects 
in the former clase, wich as. segnents containing executing programs, 
are so heavily used that hashing into the map in primary memory is 
unlikely to be efficient enough. Thus, it is necessary to hold 
the most active map entries in special hardware. 

In our inplemsatatios of TCS, this hardware takes the form of 
a special associative memory, each element of which can hold one 
map entry. The association is on IDs. On each access, the ID in 
the capability is first presented to the associative memory. If 
a matching entry is found, no reference to the map in primary memory 
is made. Otherwise, the standard map reference is done, and the 
result replaces the least active (e.g. least recently used) entry 
in the associative memory, as well as being used to perform the 
Acewen: The effectiveness of similar hardware has been clearly 
demonstrated in existing systems [Sc 71]. 

Whenever an entry in the primary-memory copy of the map is . 
updated or deleted, any corresponding entry must be invalidated 


in the associative memory. This can be done by selectively 


Frequency’ of such context evitching, 
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clearing the matching entry (if any) or by totally flanning the asso- 


ait 


Br GEE iow. BA o 


ciative memory. The cost of ‘reloading the entire associative memory 


He fgnearpo las 


teach’ such flush might be acceptabie, but the gutta < complication’ 


Pee ooo 


requited to do gelactive clearing is. so low ae it oad undoubtedly 


ye ha method of cholce. “Note ‘that total’ flushing Of the: aaucciative 


SSI EVO S45 tu 


memory is never logically n necessary, dee to Tie Wet br bontext- 


o Be: Tis ob ri Pos 
{odesendent’ names as. “aeeociation eon. Sind lat a henteae involv- 


Be dpdde gee coh SSO Gh aIges ded ie qe On Ob. e#eece yd 
ing association on context Aepandant nawes require total flushing 


clghyd Gere aL Deane opel wef aadtiw evhissisiig reddodd 
each time the context (domain, process, etc.) is switched. of 


du sat. movs 


course, the significance of” this is ‘estisaly dependent upon. the 


wie laudutte qa owls 


oe One apparent ‘alternative’ to a “apactal’ qieeeiatice ‘momory would 
ned MaTsoT wo si 


‘be’ the provision of « general: purpose associat ve memory or Mal 


Lg Oe Gute sx 


“holding the most active items’ ‘in’ primary Memory , repardicas ‘of how: 


Seuoayg, Wubi ae derbi ce bt win wits 
they are being used. Such’ a ‘ cache would” naturally tend to capture 


‘the most active entries in ‘the ‘map, aoe thus “peed up the ‘standard 
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‘machinery for ‘actensing ‘via the sap da primary memory. "tn ‘spite 
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“OF dea" ‘appealing aiiplicity, we ‘reject ‘this acheme : for several 


wo YR Fat 


reasons. For one thing, a‘cache which is large” enough ¢ to be useful 


for non-wap items (e.g. instructions, Gata) is ‘unlikely ‘to be as 


TREE 


‘fast as we can 1 afford to make special hardware: which: captures only 


) tae 
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active map éntries: ‘Placing’ map ‘entries in the same cache with 


fowrc: ¢ 


other ‘data also sacrifices” any opportunity tp: a: access “the iwo in 


BY wRatt: g fan 


parallel. In addition, ‘the he by ‘eransparendy speeding up 


primary ‘memory, in no way ‘bypasses ‘the ‘hasiaag” seoeiney ‘to ‘Locate 
a map entry. This means ‘that ‘gncice “Weotision chains! from the 


map, rather than just active entrded: ‘would ‘need *t0: ‘migrate into 


edt tafiey dugerics 


32 


the cache, and would have to be scanned on. each access, thus further 
degrading performance as compared with that of the special purpose 
associative memory. A more general way of stating all of these 
objections is to a that the cache simply makes the memory faster; 
. the relative overhead for accessing map entries in memory is thus 
not reduced by the cache. Hence a cache, wiile valuable for other 
pucoseee: 1s not optimal for capturing active map entries. . 

fnother alternative which bas been adopted in sone systens 
stems from the observation that active capabilities, as well as 
active map entries, should be held ia fast hardware. To this end, 
programiable capability registers, can be, provided, into which an 
executing program can load capabilities before, use (Pa,69,, Ba 72]. 
“Moreover, the ap entry corresponding toon getive capabaity is 
_ itself active, suggesting that space be provided in the register 
“for the map entry as welt. An gecess via quch a “onart” rogieter 
as tite peoneed: dtrectty, tothe’ ob tect, OF coctes, it ts etils 
necessary to automatically reload any registers holding copies of 
a map entry which. is updated, which adds a certain amount of com 
plication to the mechanism. Also, the addition of programmable 
capability registers, | igotzens smart or not, . introduces. the standard 
erpbiews: of _Fegister allocation, seva/seotore sequences, and 80 
on, aB well as the novel requirement. that a calling domain expli- 

citly erase registers containing capabilities not being passed as 

“parameters. Other considerations in the use of capability regis- 
ters are discussed by Needhan We 72). . 

We adopt for our _inplemantation of Tes the. associative memory 


sack rather than smart capability registers, although the 
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preference is not a strong one. We assume that the overhead of 
fetching the capabilities themselves from primary memory is suffi- 
ciently reduced by transparent mechanisms such as a program-counter 
holding the current procedure. capability, or’ hardware implementation 
of all or part of the execut $hg ‘dewasa' 's implicit segment. 

The success of the associative; meaty approach is completely 
dependent upon the observed pendency: ace oe a small number of 
objects to be heavily accessed during any given small interval of 
time (i.e., fraction of a second). 60's coarser time scale (i.e., 
minutes), the same kind of behavior te-ubsyrved in the sense that 
during a given coarse time interval most of the objects in the 
system will not be accessed at ay ae atl that the map 
entries for such objects be kept in jeecondary memory, and be brought 
.. date. the. .hagh.table.da- ‘primgry peory only when needed [Fa 74]. 
Experience with a simflar scheme. ene “petive Segment Table" [BCD 72]) 
on Multies shows that this apptcach eon be quite successful i 
saving a large amount Of primary memory ‘without ; ie tale a signi- 
ficant speed penalty. : 


Another aapect of TCS' imp inolamanfation to-be-déscussed ig para- 


meter passing during domain calls. This is included mainly as 


background for a more elaborate ‘sokepe developed.in Chapter. A, 


hence it omits details not relévant™to eae discussion. Figure 
2.2-2 shows, the workings of the demain call jnatruction. First, 
the return gate must be retained, allowing re-entry into the caller 


at the site of the call. This is saved in a pushdown stack of such 
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call (CoP, oP os. oe rPa 3) ’ 
P 


push (G,) 


P + get _ parameter (I ,Caller) 3 
put_parameter(I,Callee,P) | 


Ce 


Figure 2.2-2: TCS dommiri<cuxtl operation 


SRE RRR RE TL aE emt ar es 


* 


gates which is associated with the process. Then the parameters 
are copied from the caller's address space into that of the callee. 
We assume the existence of two sub—operations internal to the base- 


level system: 


P + get parameter (1,D) 


_. put, parameter (1,D,P) 


These operations serve to fetch and store the 1° parameter P 
at the sopraprkate locatida in the address apace of domain D. 
The actual layout of the parameters in the address space need: not 
‘concern us here. We emcee tha N,, the number of parameters, 
and Gp» the return ry are automatically available to each base- 
level operation. (Most. operations finish by exiting through Gps 
the exceptions are Uomain-call ghd domain-return.) To simplify 
the discussion, we have omitted daectipeion of the copying of 
results from the callee back to the caller when the return is done, 
. since this is virtually identical to the handling. of the parameters 
during the call. Thus, Figure 2.2-3 shows only the retrieval of 
the return gate from the stack necessary to resume execution of 
the caller. 

In concluding our discussion of TCS' igplementation, we 
briefly consider two possible ways to attack the lost object pro- 
blem, neither of which we regard as satisfactory. One approach 


is to maintain with each object a reference count of existing 


*, variant of the call operation, referred to as a "jump-call" is 
obtained by omitting the saving of the return gate. This causes 
the callee to return not to the current caller, but to the pre- 
vious caller. This is occasionslly useful, as we shall see in 
Chapter 4, , 


36 


return( ) 


ENTER 


EXIT thru G 


Figure 2.2-3: TCS domain-return operation 
(without results) 


cee ge 


capabilities, and to delete an object when it coehaes lost, as well 
as when it is explicitly deleted.* There are at least three draw- 
backs to this approach: a ae | 

a) ‘The destruction of capabilities (e.g. through overwriting 


or segment deletion) sust be detected and the reference 


ep ht tater c4 


counts maintained. 
b) Lost selt-referent ial structures are not deleted properly. 
c) An object may be lost to che user Who ‘funds it, even 
though capabilities exist ‘eisevhere. | . 
We therefore reject the fefarence’ count approach. (ior © conteaey 
“view, ace Wolf; etal! (wu 741) ~ : 

Another “approach is to allow “un—losing" of lost objects by 
allowing a suitably authorized domeis (e.g. coe which owas the 
funding account) to request spontaneous generation of fully privi- 
leged capabilities for funded objects [cC’69]. This is rather 
analeoest ‘and ‘requires fairly complicated” ‘deta: ‘gtructures which 
may or may not be otherwise necessary. ee 

Other approaches to di base-level solution to ‘the lost object 
problem can be envisioned (e.g. globai garbage coliection) but we 
cease instead to postpone the solutfon until a higher level of the 
system. Thus, ‘the base-level system simply aiiows objects to 
become lost, and the users depend upon the directory system, as 


pe 


described in Chapter 4, to prevent ‘this. ‘occurrence. 


A Ohne he Ges 


& . ; 

We assume thet explicit deletion id alec jdvaiiable; since other- 
wise, the user who funds the- sat bee = ita — to rectet@ the 
space occupied = it. 
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2.3 Revocation of Access Privileges 


In the context of TCS, we now explore various approaches to the 
distribution of capabilities and the revocation of access privileges. 
As an example, we use the simple situation in which domain A 
wishes to grant to. domain B a set of privileges to access object 
xX. 

The first approach which suggests itself is the simple copying 
from A to B of a capability for X containing the desired 
privileges, as shown in Figure 2.3-1. This ie clearly the intended 
as of copyable capabilities, and is quite satisfactory provided 
that the amount of trust A has in B remains conatant.” If, 
however, A_ subsequently decides that some different set of privi- 
leges is more. appropriate for B, a second capability for X must 
be passed as a replacement. This may be quite inconvenient for B, 
who may have made various copies of che original capability, some 
of which may have been passed on to other domains. Moreover, 
unless the privileges in the new capability are a superset of those 
in the original, A must pessimistically assume that B will 
retain both capabilities, and Shue possess the ynion of the privi- 
leges in thie two. In other words, privileges once granted can néver 
be revoked. 

This simple example shows that the gd esl capability mechanism, 
while useful, does not adequately cope with the difficult situation 
of changing levels of trust, particularly when trust decreases and 


, revocation af:, privileges ig desired... Before proposing any 


"we will generally omit ‘the gurase “the. pateen whe. OWRS &: "domain" 
and simply inpute feelings of "trust" and "suspicion" to the 
domains themselves. 
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capability propagation 


Figure 2.3-1: Passing a capability 
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fundamental changes to the behavior of capabilities, however, it 
seems appropriate to explore the various approaches which have 
been proposed for solving the revocation problem without making 
any major modifications to the underlying capability mechanism. 

Caretakers: A standard “escape hatch" in most Scepen tid 
systetié is the ability to interpose # "caretaker" domain between 
an object and the domains which acedag it. The davataxes can 
_ implement any access control protodol not provided by the system. 
This situation fe shown in Figure 2.3-2, in which A has created 
a caretaker domain C, and given to DB. a capabfiity to call C, 
rather than a capability to access X directly. Two problems 
are immediately evident. “One is simply the inefficiency of 
calling C each time B agcesses X. For example X may be a seg- 
ment, in which case the once domain-call is likely to cost much 
more than the segment access itself. The other problem is that 
B now receives a capability of type ‘domain' rather than one 
indicating the type of X. Unlegs the system provides facilities 
for allowing domains to "masquerade" as objects, this will change 
the interface seen by 5B when accessing X. For example, to 
store into a segment, B must execute either a store-operation 
or a domain-call-operation, depending on whether or not a care- 
taker has been interposed. 

More generally, one can object that the caretaker mechanism 
is not, in itself, a solution to the problem, but merely a frane- 
work within which a solution can be implemented. We have said 
nothing so far about the basis upon which the caretaker c decides 


to allow or refuse a given access request. In the simplest case, 


Al 


call-only 


Figure 2.3-2: A caretaker domain 
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A specifies a single set of privileges and gives a corresponding 
capability to C, who exercises it each time B (or ariy other 
domain having a copy of B's capability) ee an access. When- 
ever A's ‘eval of truest in 8B decreases, « a “weaker capability can 
be given to C. On the other hand, if A-whshes to confer inde- 
pendent ly tevoeable privileges to acess es ‘ow Various domains 
by: authorizing them all to call C,° ten = oe given that it can 
distinguseh. reliably atween its arious ‘cailgre, ‘finds itself in 
the position of a proce@s in Lagipeon’ "menage system" [La 71]; 
that is, C must eopentially reefivent the system! 8 protection 
machinery. This can be avoided by defining multiple caretakers 
for X, each allowing : an independent apt of privileges, as shown 
in Figure 2.3-3. Since ‘the ‘caretakers in this situation are not 
really making any decisions, ae fe merely using their privileges 
whenever requested, one would hofe that the overhead of an actual 
domain call might be avoided. We will return to this point later. 
Control: Most modern protectidn systems provide some mechanism 
to capture the notion af one domain being subordinate to, or under 
the control of, another domain. This is sometimes represented by 
a static domatn- htérarehy [St 73], but wa.will treat control as 
being a privilege which, when contained in a capability foe 
domain, authorizes the possessor of the capability to control that 
domain. (The distinction is not very important for’ the discussion 
which follows.) In our typical system, much of the power of con- 
trol can be granted by giving one domain a suitably privileged | 
capability for another domain's implicit segment, as eae suggested 


in Figure 2.1-1, although complete control would require a 


Figure 2.3-3: Multiple caretakers 
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capability of type ‘domain' allowing access to the controlled 
domain's domain-descriptor. 

This facility for one domain to control another is applicable 
to a subset of our problem of changing degrees of trust; domain A can 
attempt to enforce any reduction in its degree of trust of B by retain- 
ing tontrol over B, although this requires that B have total 
and unconditional trust in A. The latter condition clearly limits 
the class of situations in which control of B by A is appro- 
priate. : | . 

Even when the control facility is applicebie, ‘there are still 
problems with its use. It would appear ttias. A, ‘having given a 
capability for X= to controlled domain B, could later search 
the entire address space of B, ’ reducing the privileges in all 
copies of the capability to match its eéutled intentions. The 
success of this search, however, tan be compromised if B is 
allowed to exacute concurrently, making the capabilities in ques- 
tion "moving targets." Thus, concurrent execution by. B (or any 
other domain able to manipulate B's address space) must be pre- 
vented, either implicitly by placement in the same process with 
A, or explicitly by being "stopped" by i‘ using its control 
privilege. | - 

Even if. A manages to waceeaseulty weaken the capabilities 
in B's address space, there remaing the possibility that copies 
may have bucupad to other domains which are not under A's control. 
To prevent this, A must carefully limit B's communication with 
other domains via shared segments, domain-~call parameters, and. so 


on. In short, B must be "confined," which, as noted by Lampson 
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(La 73] can be both very restrictive for B and very difficult 

| for A. In the latter regard, however, it is worth . noting that 
the problem of “covert channels" does not exist for capabilities, 
since Eeansaisston of the bits ofa capability ig not the same as 
transmission of the capability itself. ’ 

A simpler mechanism which has been proposed (la 7, Gr 72] 
Sa with the above problems uses a "copy-flag" contained in 
each capability. Originally, the flag is on to allow copying, but 
once it 4s turned off, it can never be turned back on, and all 
| copying of the capability is disallowed. Thus, A . gan place a 

non-copyable capability for. x in B's address space, and later 
| revoke any desired privileges from that, capability, confident that 
no other copies exist. This is eyen more of a restriction on B 
than confinement, however, since free copyability is one of the 
fundamental properties of capabilities. If one assumes that the 
passing of capabilities as donajn-call parameters is done by copy- 
ing, then aoe coRyebre coment tcsen. canpot even be passed as para- 
meters, making them virtually useless. The schene can be salvaged 
by introducing "indirect capabilities" which point to the non- 
copyable capability and are themselves copyable, but, as we will 
see later, auch an indirection feature. 1s powerful, enough to com 
pletely eliminate the need for A to, control, B in the first 
plate. | eye Sateen , 
Ownership: The idea of one user or domain "owning" a shared 

object has appeared in many systems, for such purposeq as account— 
ing and resource allocation, as well as for protection. In the 


context of protection, the owner of an object is thought of as 


“ 


retaining ultimate control over the object, in the obese that any 
other domain's capability for the object should be subject revo~ 
cation by the owner. Ownership, like control, could be defined 

as a static relationship between each object and its owning domain, 
but again, we assume instead ‘that ‘ownership’ 4s simply a privilege 
which confers 'owner' status ‘gn any possessor ofa capability con- 
taining it. | | . 

As described thus far, ownership avoids the problems which 
limit the applicability of the control scheme. In particular, it 
is usable in the case of mutual suspicion, since it makes no assump- 
tions about the relationships between domains. However, several 
issues have been left unresolved. eee _ 

If the owner of an object wishes to revoke eghcen sec of 
privileges from all outstanding capabilities for the object then 
the desired: action is clear, if somewhat impractical. “The base 
level system must pesnead all other eativies: ‘and search the addtess 
space of every domain in the system, performing ‘the aporopetaes 
reduction on each capability for the object fn sueation: It is 
worth noting that one case of ‘sich anitatn: revocation has’ a much 
more reasonable interpretation; if all privileges are to be 
revoked from all capabilities for the object, the owner can en eeere | 
make a copy. of the object sad “deaceoy the original. An even more 
efficient mechanism to produce the same effect can be provided in 
the context of the implementation in paction 2.2 by simply allow- 
ing the owner of an. object to change its. ID, thereby invalidating 
all outstanding capabilities [cc 69]. (Of course, the operation 


must return to the owner a new capability containing the new ID.) 
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If the owner of an object wishes to revoke individual privi- 
leges, a global search is implied, as indicated above. If, how- 
ever, the owner whehes to revoke ‘these privileges from some but 
not all of the capabifities | ‘for tie object, ‘even more fundamental 
problems arise. “The central question is how. the owner should 
specify. the set of ‘capabilities on watch the revocation is to take 
effect. Tn the context af TCs, the énly ebvious possibility is 
: the. aperification of a set of dougins in. tehich the fevocation 
: should occur, either Py Hoting thy yet ‘by Listing the comple~ 
‘mentary set of amen tie’ ‘whieh should ‘Semain | unaffected. The pro- 
blem is that ina syaven\providing pean a ae capabilities, 
the owner of an object ig unlikely to have complete knowledge of 
“the Pegpeentece of capabilities for that dbjact’ throughout the 


system, ‘and is therefore not ina positioh to eves either type 


of 4 domein- iist. . Figure 2.3-4 depicts. che altgibipa “in which A 


has gives capabilities for owned object. ‘ to B and ¢ Sub~ 
sequent ly, B and C have passed copies oftheir capabilities 
to D and E, respectively. If A now decides to revoke some 
privileges from B's gapability, the revocation should clearly 
effect D's capability, but not | C's or E's. A domain list pro- 
vided by A to COnErOL the _revpeation would specify either revo- 
cation from B, allowing D to SRCAPS or exemption of C, 
incorrectly affecting E. 

There are other relatively simple situations in which no 
correct domain list can = prepared, regardless of A's global 


knowledge of the distribution of capabilities. among domains. 


Figure 2.3-5 depicts such a situation, in which domain D has 
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Figure 2.3-4: Ownership _ 
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Figure 2.3-5: Multiple sources of capabilities 
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received capabilities for X from both B and C. Ideally, revo- 
cation of B's privileges should affect the capability which D 
received from B, but not the ones received from C. Such distinc- 
tions clearly cannot be expressed in a domain list, and require 
of A a completely unreasonable amount of knowledge of the inter- 
nal structure of other domains. | ‘ 
Yet another fundamental problem involves the authorization 
of revocation by domains other than the orginal owner. In 
Figure 2.3-4, for example, B stands in much oe ao palationshi¢ 
to D as A does to B, hence it would seen gssadvie to allow 
B to revoke the privileges it granted to D. Since ownership is 
a normal privilege, A could authorize this by simply including 
‘ownership’ among B's privileges, but thie clearly gives B too 
much power (e.g. the ability to interfere with ¢ “and E). Simi-~ 
larly, in Figure 2.3-5, B should be authorized’ to revok¢ the 
privileges of the capability it has passed'to D, but sot the one 
D “has received from C. 
Thus, the privilege of ownership, while sufficient to author- 
ize the total revocation of all capabilities for an object, is| 
insufficient to deal with a general situations. 


Indirection: Most of the problems with revocation in capa- 


bility systems seem to be caused by the propagation of capabilities 
throughout the system. This suggests that domain A in our exam- 
ple should aeece give to B a capability for X whose privileges. 
it may subsequently wish to revoke, but should retain the capability 
and give B a "pointer" to it. The success of thie approach is 


very sensitive to the exact nature of the "pointer." 


From domain A's point of view, the most obvious kind of 
pointer to the capability is simply ite address in A's address 
space, but this address by itself is meaningless to B. To use 
the address, B needs to specify that it should be interpreted 
relative to A's address space, an action which clearly requires 
_ authorization in the form of a capability for A ‘Gr for A's 
implicit segment) allowing capabilities in A's address space to 
be exercised, but not fetched or stored. . Giving such a capability 
to B clearly compromises A, however, since _B may use it not 
only in ogee with the pointer provided by A, but also 
with any other pointer B may invent. Moreover, this scheme 
also causes problems for 8B, since instead of a single capability 
for X, a capability for A and a pointer must be used. Thus, 

B effectively receives the absolute address Oy he” where A, 
is the multi-level address of X in A's address space. These 
problems can be reduced somewhat by the obvious expedient of giwaye 
passing the simple absolute address $C,d> of A's capability 

for X, thus limiting A's vulnerability to a single segment, and 
guaranteeing that the pointes which B must handle will always 

- a giapis displacement. Moreover, if this simple absolute address 
can itself somehow be squeezed into a single capability, both 
problems have been solved, since only the single "slot", in A's 
aiazeak space which contains the capability for X is usable by 

B, is need only keep track of the slot. capability, rather than 

- Sgpabiticy aid a pointer. Of course, care must still be taken 
pee B to ignore the difference between a slot capability 


and a capability for the desired object. : 
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een ignoring the problem of squeezing so much information 
into a singlé capability, there are still restrictions on the use 
of indirection through capability slots. The problem is that such 
slots can néver be reused. For example, suppose that A passes 
to B a capability for the slot containing one of | A's own capa- 
bilities for X, as shown in Figure 2.3-6. If A later decides 
to revoke all of B's privileges to eoceus x ‘by erasing the capa- 
bility from the slot, B still retaine its slot capability. There- 
fore, A must be very careful never to place gaotha® capability 
in that slot. 

One ni of attacking the non-reusability problem iG to squeeze 
still more information into the slot capability, namely the ID of 
X, and to check on each access that this ID matches the one in 
the slot. ‘This eases the restriction souaveat: a alee may be 
used any number of times, but only once for any given.object. Com- 
plete reusability of slots requites the inclusion of a "slot tp" 
in both the slot capability and the capability in the slot, to be 
compared on each access. This essentially amounts to re-invention 
of the unique ID mechanism of the base—levei system, and is likely 
to be very cumbersome, for both user and implementor. 

The non-reusability of slots in the indirection achene is nee 
really a fatal flaw. It simply forces the mechanism to be used 
in a rather stylized way. For example, domain A, rather than 
. giving 3B a capability Yor some location in its own data struc- 
tures containing a capability for X, must copy the capability 
for X to some spot which will never be used for anything except 


indirection via B's slot capability. Actually, A would 
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Figure 2.3-6: Indirection through a "slot" 
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undoubtedly have made an extra copy for B's use in any case, so 
that subsequent revocation of B's privileges would not interfere 
with A's own accessing of X. Thus, the only real burden on A 
is the careful allocation of slots so that they will never be 
reused. One approach would be be net aside one’ segment of A's 
addres@ space and sllocate slots in 1t sequentially. A much more 
attractive, if rather more expensive, scheme is the creation of a 
tiny new segment to hold each slot. This ‘not ‘inly takes advantage 
of the base-level allocation machinery, | ‘but also implies that the 
displacement which we squeezed into the slot capability is always 
zero, and hence may be omitted. 

Privilege revocation by indirectiog through such "link" seg- 
ments is actually a fairly attractive scheme, which we pursue in 
some detail in the next section. It is conceptually related to 
both the caretaker and control schemes discussed ubove. If one 
thinks of the link segments as domains, in the passive sense, then 
indirection through such a link déeatn is ‘much like calling a 
simple caretaker which merely exercises its capability on demand. 
(Note, however, that the cost of an actual domain-call has been 
avoided.) On the other hand, from the point of view of its 
creator, this passive caretaker is a very well-behaved controlled 
domain, since there is no possibility of its capability being 


copied or moved. 


2.4 Indirection Through Link Segments 
Since indirection through link segments created especially 


for that, purpose seems to provide many Apsifable features for revo- 


cation, w e now pursue this APPRQARH sopavhat, MOTE, yigoroysly. The 
discussion is still in terma of TCS, in the senge that we attempt 
to minimize modifications to the bape-level expten Ane construct 
the revocation machinery “on top of" that syeten,, Although we 
| will Jater argue that 9 fairly complex revocation facility should 
instead be included in the base-level system, it. is useful, to | 
explore this higher level implementation asa first step. 

As mentioned during the discussion of ienacsiie. it is 
desirable for any possessor of @ capability to be able to distri- 


bute copies of it while Sprain ds the pe to evens: the privi- 


“leses thus conferred. ‘Thus, if access s privileges p pass Eheough the 
hands of several a ees A ae Link seguents 

iets pvineetelg~-oo. td 
| form a chain. Capabilities siecrag cia ERat chala are subject 
to. evocation by any ‘of the “Gtatetbutors. Any possessor of such 
a capability may extend “the chain by creating a link segment and 
arching the capabeitey in ice pete Glan ‘a powerful capability for © 
the link segment allows later reduction of the privileges in the 
‘capability stored there. If and ‘tian ai privileges are to be 
Secs, the link : segment can be PUCn ie ee 
Thus fer, we » have ade no o changes at all to the TCS base- 
| level capability nechanien, but wine ie a. niovigied any way 
ee the indirection chains to ‘be used to access the target object. 
“This w will require. a | fairly simple = modification of the base-level 
“system, b but before describing that , modification, it is instructive 
to observe » precisely what goes wrong nee ae ene Fe do without it. 

Fe Ge GO wan | 


In terms of our - standard 1 example ge AS giving B privileges 
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to access X, we find that A, tai Hguee 2.61, having created 
link segment s,, and stored its capability C. for X there, 
must now give to B a capability cq ’ for — Clearly, B's 
capability G, must not allow B to tamper with the capability 
in S), but only to use it as a component of a multi-level 
address for X. (For éxample, if X is a segment, B's address 


for its 5th word, given that C, is located at location 3 of B's 


L 


implicit segment Sy is 


3|0|5 = <((C,,3),0),5> = <(C,,0),5> = <C),5>  .) 


There are four interdependent problems with this attempt to 

implement link segments on an unmodified capability systen: 

1) Non- transparency: A domain accessing an object must 
know how many Links are . present in the chain leading 
from its capability £5: the object (4. ihe many 0's 
to insert in its multi-level sais as in "3|o|5" 
dbove) 

2) “Ambiguity: A link in the bhatd is indistinguishable 
from a target ohiect which happens to ‘be a segment con- 
taining a capability in location 0. 

3) Subvertability: This is really implied by problems (1) 
and (2); if the accessing domain accidentally or mali- 
ctously specifies a multi-level. address which is too 
short, it can obtain a copy of a . capability stored in 
the cheans thus circumventing subsequent mevocerton: 


4) Loss of galective adjustment in long chains: Only the 


last link in the chain contains a capability whose 
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Figures 2.4-1: Example of indirection 
through a “link" segment 


58 


privileges apply to the target object. Bach éarlier 
link contains a capability whose privileges apply to the 
next link in the chain. The only revocation allowed by 
such a link is total revocation by breaking the chain. 
All of these difficulties are avoided by a pimple modifica- 
tion tothe base-level system, which tne rodijces ite operation 
on capabilities, and changes the -behayior of the base-level system 
slightly when a capability is encotatered to which this operation 
has been apn ided | - 
The new operation allows capability of type leaguer! to 
be converted into a capability of type ‘indirect’ in which all pri- 
vileges are 'on.' (As we shall see later, this is just a specific 
inetende of a more general mechanism useful for type extension.) 
The intention is that euch indirect eapabilities for link segments 
should be handed out to domains which are being given revocable 
privileges. For example, -4n- Figure 2.4-1, the capability Cr 
which A gives to B must be of type ‘indirect, ' although A's 
own capability for: s ‘ta of kypaéiegeent.’ 
Whenever an operation which expects a capability for some 
object encounters instead a capability of type ‘indirect,’ the 
| indirect capability is followed; that is, it is replaced by a copy 
of the capability in (location 0 of) the segment to which it points, 
with any privileges deleted which did not ala@o occur in the ori- 
ginal ‘iipece capability. This step is iterated, as necessary, 
until the resultant capability is not of type ‘indirect, ‘ at which 
‘point the operation proceeds as usual. 


Thus, each time an object is accessed via a chain of link 
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4. Reduction of the privileges of the » capability 1 in the 
link to an appropriate ‘level. 
5. Distribution to the receiving domain(s), of copies of 
the indirect capability Produced in step 2. 
Any later reduction in level of trust can mes enforced + re~execut- 
ing step 4, ‘epeed tying some reduced set of privileges. - 
 Alchough thie indirectiea echeme dias. & Sexaddable 4ob-0F 
capturing the ‘notion that a distributor of a s capability should 
retain the power to revoke the privileges it confers, it gives 
one the feeling that the desired mechanisn is being “aimilated, . 
in the sense that the basic action of dtetributiog a ‘capability 
‘is provided by a particular non-atomic ‘sequence of operations, 
rather than being an atomic operation. “this | has two > consequences: 
a) it is inconvenient for the user. _ | 
b) It may allow other sequences of operations to , produce 
a non-meaningful state. “ 
The former beob len can be easily dealt with by providing, a simple 
library procedure to perform the actions required for: capability 
distribution. The latter een however, ts not 20 easily dise~ 
posed of. ‘Suppose, for etemple, that by eecuuane or r design, @ 
domain, in performing step 3 of the procedure, stores not the 
appropstate object capability, but the indirect capability created 
in step 2. This is just one way in which circular inditection 
chains can be created. Such chaine, when followed, will cause an 
énateun dean. tn the base-level syaten. “Of course, one could deal 


with such a situation by placing an arbitrary Limit on the length 


of an indirection chain to be followed before it is, abandoned and 
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an error nae signalled: but thts is Fechner ad hoc a inelegant. 


An atomic operation producing only well formed chains woutd be 


$x) 


sich more atévesrive, 


Another prabies tdci this scheme is its relative inefficiency. 
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For | one - thing, it would generate large numbers of ‘onal pegnents: 
This could be extrenely costly in terma of both space “and time, 


ney : Pat 4: 


especially in a system using block-ortented rotating magnetic 
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storage ‘gad a 1 corresponding paged primary meaner): For another 


Ate) faah : 


‘thing, cha scheme requires the following of a ehas Of | sinks each 


time an indirect capability is exercised. thie overhead could 
3: baits et EEE Ls? peel yt we bids ee Pail 
prove ‘prohibitive, particularly in the case of indirect access to 


Powak ab cand Shee 


—— Moreover, any nechanien attempting to corer a@ compu- 


tation’ 8 set ‘of recently used chains and retain them on feat hard~ 


FB rE 


ware would be complicated by the fact chat every | store instruction 


Oe wor 
would have to be regarded as ‘potentially Anvalidating ¢ this "look- 
3433 ‘ od byhe 
back" information by overwriting a Link in boegae chain. 


By spear leons if equivalent revocation features | were built 

ge ted woe ts . 
into the base-Level eyeten, chey would probably be easier to use, 
harder to “mieuse, and | more anenable Ae "optimization. This approach 


pepe Le ma, : tes 234 


is eislored: in detail in Chapter 3. 


2. 2. Type Extension 


‘The definition of a | Large complex system as: a sequence of 


sit i §g aime 


"layers" has been found to be a valuable technique, aiding all 
‘ eae) ob eR Dera i. 
stages, of design, inplenentation, testing, pa documentation 
i Pre) : i. ae Febiee 
bt 68b, Pa 72, La 69]. Tn an object-oriented eyeten, this implies 
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. that not. ALL of the various types of objects provided will be imple- 
mented, or even known about, by the base-level system. “On the 
other hand, it would be most inconvenient ie the dining and pro- 
tection machinery provided by the base~level system d. e. capabil- 
ities) had to be reinvented by each new 1 layer of the system; this 
would not only raise serious problema for the implenentation, but 
would also force the users to interface with several berets 
mechanisms for storing privileges, Wesabe: privileges to other 
dcunios. and so on. It is cneterore very desirable for the base- 
level capability machinery to provide capabilities for ects 

of which the basen tered mystem on no knowledge. 

The various base-level, facilities tavolving capabilities can 
be divided into two categories. In the first category are the 
facilities eevOLVERE capabilities themselves: “their creation, 
integrity while stored, "copying, erasure, and so on. In ‘the second 
are the facilities. fot nanipulating base-level objects named by 
capabilities: fetching fron. a ‘segnent or calling a domain, for 
example. It is the facilities in the “fizee category which can and 
should be provided for higher-level objecte unknown to the ‘Veta 
level system. | . . a 

As indicated in section 2.1, a capability provided by TCS con- 
tains the type of its corresponding object. The asvieion of the 
set of all ai into types is a well tien and intuitive idea 
(although, as tear out by Morris [Mo 721, the difference between 
the type of an bhiact and the privileges alloving access to it is 
couatak indistinct). , The set of. ‘objects provided by the ‘hasaclavel 


system falls into some cmili fixed number of types. ‘The question. 
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is: what type of capability is used to name a higher-level 
("extended") object? Various answers have been proposed, four of 
which we will explore. 


roach 1: Re resentation ca bilities. Any given layer of 


the system runs in an environment provided by the lower layers, 
hence any object it defines must be represented in terms of lower 
level objects. We will aseume that the representation of each 
extended object is a single lower level object, since that single 
object can be a segment containing capabilities for any other ob- 
jects which are necessary. Thus the most obvious candidate for 
the capability for an extended object. is, simply a capability for 
the representing object. A possessor of that capability could 
call the layer implementing that extended type to request some 
operation, and pass the capability to indicate the extended object 
to which the operation should be applied. Having been passed this 
capability, the domain implementing the extended operation would 
automatically have access to the representation of the object, 
‘There are at least three problems with this approach. The 
first and most important concerns the selection of an appropriate 
set of privileges re appear in the capability. The difficulty is 
.that the domain implementing the extended object requires egsen~ 
tially complete power to manipulate the representation, while 
wishing to deny such power to the using domain(s) in order to 
prevent tampering with the representation. If the same capability 
is used by both, this is clearly not possible. Hence, the imple- 
‘Banting domain, heving upon request, created the representation 


of a new extended object, and thus obtained a fully privileged 
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capability for that representation, must app tiinitatély weaken that 
Saivebidiey before returning it to ‘the calling vedi dcsidin. However, 
in order to guarantee ita own future access to the representation, 
the ‘implementing domain must do one of two things. fither it must 
gave a copy of ‘the original fully privileged capability ‘for later 
use, or it must make arrangements allowitig it to convert the weaker 
capability back into the fully privileged ‘one when it later receives 
it as a parameter to some operation on the extended object. 

The first method obliges the implementing domain td maintain 
a global table containing privileged capabilities for all existing 
extended objects which its layer has created, and to locate the 
corresponding entry whenever it receives a weak user capability. 
This method is reasonable, if somewhat Clumsy. = . 

The second method requires some facility siuilar to Jones’ 
Wamp Licatton" [Jo 73], allowing the “tmp lament ing domain to add 
specified privileges to capabilities of the type of the represent | 
ing object. Clearly, the power to amplify capabilities of a given 
type is a very dangerous power, and must be tightly controlled, 
since it can Completely subvert the inter-user protection of 
objects of that type if misused. ‘Whtle this 4s an incomplete sub- 
version of the objects in question, in the sense that they still 
follow thé sensatic rules which define their type, it must be 
’ regarded as a failure of the corréspondiig layer, wince the correct 
functioning of a layer includes the protection of its users from 
each other. Thus, the authorization of amplication ‘mist be the 
responsibility of the layet implementing thé type whose capabilities 


are being amplified. One of the dain criteria of layering, however, 


is that a given layer should have no knowledge of higher layers. 
‘Thus, it is not possible for a layer to distinguish between "legi- 
timate" higher exe which need amplification, and untrustworthy 
domains which would use amplification to gain undesired access to 
other domuitin’ siieeeae. We thus conclude that privilege erie 
cation by itself is insufficient to serye the Problem of assigning 
appropriate privileges to the using | and implementing domains of 

an extended object, given that the same type of capability is used 
by both domains. (in conjunction with another complementary 
nechanton (“constituent rights" [Jo 731), however, amplification 
can prowads a very. powerful type extension facility which is equi- 
valent to one which we will describe later. ) 

The second problem with ‘the representation-capability approach 
involves the control of access to the extended object, as opposed 
‘to its -Feprepentatton, Privileges are needed in each capability 
ste specify which of the operations on the extended type are author- 
rized to possessors of that capability. This certainly cannot be 
‘done by asat ening, new ‘mesnings to the existing privileges, since 
granting the use of some operation « on the. extended object would 
then imply granting sone unrelated access ¢ to the representation. 
Hence, multiple sets of privileges cm needed. _ On the one. hand, 
this cande to make capabilities undesirably large. On the other 
hand, fhe number of sets of privileges provided Places a fixed 
upper bound on the sania of times a base level type can be extended, 
This situation is especially frustrating since in most capabilities, 
onty one of the sets oF ‘privileges | will be non-empty. | 


The third problem with the representation-capability approach 
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is the difficulty of determining, given some capability, the type 
of the corresponding object. This is caused by the "unofficial" 
status of extended typés in this approach. A given base-level 


object may have been extended one or more times, but the type 


“fields of all capabilities for it still contain its base~level 


' type. The only ‘Indication that ‘the capability is of a gives 


extended type is the presence of a 1 matching fully privileged capa- 
bility in the previously mentioned table ape by ‘the domain imple- 


menting that extended type. Thus, one is not able to ask ‘of a 


given capability "what is its type?" ‘but only “ts it of type T?" 


for some list of types tT. ‘This is a clumsy and costly mubacstate: 


Approach 2: Domain capabilities. “This approach is, ‘fn some 


sense, a variant of the previous approach, in ‘Which the represen- 
tation of each extended object ‘ie ‘a domain. A wi cs tag domain has 
only one privilege in its capability for this ‘Pepresentation domain: 
the privilege of calling it. rh perform ai siteaied operation, 


the user performs such a call, indicating only the operation to be 


_ performed; the object to which the operation applies is implicit 


in the identity of the called domain. Actually, this approach 
falls outside the framework of our discussion, since it ‘requires 
independent domains callable by any process (at least if extended 
objects are to be shared). It deserves ‘mention, however, since 
it has been used in at feast two systems [En 72, Fa 68], and 
because it attacks the three problems of the representation- 
capability approach, with somewhat mixed results. i 

The first problem, that of easily allowing only the inple- 


plementing domain full access to the object's representation, is 
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‘bypassed, since each object has, in eEfects its own GORY of that 


at 


domain, which can *retain a 2 privileged capability for the rest of 
the representation in some convenient location ia its address 
space. 


The ‘second problem, that of ‘controlling ; access to the extended 


object, ‘Me solved by embedding in the domain information aout the 


operations it is willing to perform. “Thus, privileges for extended 


Seley 


| objects are represcdced and controlled differently for base-Level 


and extendad objects; whenever | a | Less privileged capability for 


an extended object is desired, a “copy of the domain can be made, 


"which is then ordered never to perform ‘the operations being denied 


to receivers of the lene privileged capabilities. This is not as 


expensive a  aglution:; as it might appear, “for two reasons, First, 


Ep fe Bp ge 
SQ So 2 tales 


the various copies of the domain representing a : eevee extended 


ogy 


object can retain in their implicit segments the information spe- 


SHES cries 


“ eifying the dpevations they are willing ‘to perform, gaa can thus 


share all the: other ‘identical components of their address: spaces. 
Second, the capabilities for a given objeae. “exhibit a strong ten- 
dency to fall into a small demaher of ‘subsets, each containing capa- 
bilities with identical privileges: (a tendency which we shall 
exploit later). pues the number of ‘copies "of the domain repre- 


senting a given ob ieee bende to be much snaller than the pusher 


of capabilities for the object. 


The third problem, that of determining the type of a eiet 


object, is handled in an interesting if somewhat clumsy way. 


Clearly, skamiaation of the capability will always indicate the 


type to be tdonaiu.’ One can | establish a | und form convention, 


' 8 BTR 
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sieht for associating some arbitrarily chosen Sesave capability 
with each eeranded type, and aoe a copy of that ee eeu in 
some standardized location in each domain m g- location 0 of its 
pe ee segment) repr sesot tae an object of aaa type. If users 
are allowed to exanine that location, they ea can “then rel iesty deter- 
mine the type of ‘nck extended object. the main ‘objection to this 
aches is that base-Level types and extended types are represented 
differently, which disallows any uni form type-checking mechanism. | 

There are some other problems Aaoaaress to che domain—capability 
scheme. ‘Two ‘difficulties arise from the fact that the domains 
implement ing the extended type are associated vith the objects of 
that type, rather than mith the acceaning procescen. One reason 
for wanting to associate a domain with each process as the "repre- 
sentative" of a given layer is that the local storage of the domain 
provides a natural repository for information ae the status 
of that process from the point of view of that layer. This "own" 
storage is not provided by a achene which aseoctates ecas ine with 
extended objects instead of Jpeocesens: [ra 74). gone systens have 
made heavy | use of euch own storage (e. g- CAL-T38, E saeenee, it is 
not clear to what extent this is intrinsically necessary. 

Another minor ifficulty with the domain-capability approach 
ie its implicit assumption that all operations on ¢ extended objects 
are monadic. While this is undoubtedly the most Common case, 

. exwplee abound of useful cere oe witich apply to two or more 
objects ("Elle-to-file copy"), to some Large implicitly defined 
| set of objects ("close all open files") or even co no sae ck at 


all (“create a file"). Forcing such Gatecions ines the mold of a 
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call on a particular object is not only artificial for the user, 


but can be mercies inconvenient for the implementor. 


Aj eeath 3: Sealed-data ca abt, atts - ‘This approach is moti- 
vated by the following observation about the use of representation 
capabilities in Agpedach 1: If the using fomains are not allowed. 
direct access to the representation of an extended object, and if 
the pap lenen Tans domain alvays replaces rhe user's weak capability 
with the corresponding strong one saved in its. own table, then the 


user's weak capability is never _setua}ly, used, to access the repre- 


sentation. This suggests the , possibility of changing the type 


ste in =e user's capability fo. contain, not. the type of the 


representation, oat some new value associated with the. type of the 


extenied object. ‘There are two Sietince advantages, to this change. 


‘On the one had, it provides an easily visible on unforgeable 


(given mechanions to be described shortly) indication of the type 


of the expensed Ob Ieee On the other. /hand, it renders the capa- 


bility upelena for Sar eeEty. accessing. the representation, thus elin-~ 
inating the need for a separate set of privileges to control 


euch acceres as was required in the representation-capability 
‘ ESS 4 th aan ea ae il Pe 5 she ae 


approach. 


From the ‘acemaieng t domain's vieueide. the creation of a 


new extended object using this approach could he Mone. by. 


7) creating a ‘representation of phe object eagithcd 
2) saving a fully privileged capability for the representa 
tion in a hash table keyed on IDs S saieie nat | 
3) constructing a new capability containing the extended 


_ type, full privileges, and the ID of the representation, 
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and returning it to the caller. 
When called to perform some operation, the inp lementing domain can 
examine the passed capability: | 
1) checking the type to verify that the object is one that 
it implements 7 ad : | 
2) checking the privileges to verify, that the requested opera- 
tion is authorized. 
3) ‘locating the representation capability in its table and: 
‘perforniag the operation cis Che peneeeehtation 
Cleatly, the creation of capabilities for extended objects 
must be carefully controlled, ‘since a forged capability could deceive 
not only the users, but also the implementing donain. The creation 
of capabilities of a given type can stents be authorized by a capa- 
bility. When this capability and an aeehttary. ‘decane are presented 
to an appropriate new base-level operation, a new capability is 
returned with the authorized type, all privileges 'on,' and the 
datum as its unique ID. (As suggested above, this might be the ID 
of the representation, but could be ‘any value desired by. the imple- 
menting domain. ) “Section 2.6 will discuss how such authorizations 
to create new capabilities can themselves bal ceeuted and distri- 
buted. | sala _ 
The sealed—data approach de desceibed Gee gaits acceptable 
type extension mechanism, and has in fact been ceed in at least 
one actual system [St 73]. it siaces each higher layer in much 
the same position as the base-level system; a capability is regarded 
“ holding an ID sealed in ao Gampedatoo® box. ach guarantees 


that the name presented by a user is in fact a valid name given 
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him by that layer. Furthermore, it allows this. without forcing 
re-invention ot the sealing mechanic in each new layer. It does, 
however, require that each new layer implement its own table for 
converting an ID into 4 capability for. the representation of the 
corresponding object; this ds a partial duplication of the function 
of the base-level "map" of section 2.2. It is desirable to avoid 
re-invention of the map, as well as of the capabilities themselves, 
an advantage possessed by our fourth approach to type extension. 
Approach 4: Sealed capabilities. The need for each layer to 
maintain a table mapping extended abject capabilities into repre- 
sentation capabilities. can be eliminated 1f the system simply 
allows each extended capability. to contain the corresponding repre- 
sentation capability, The extended capability thus becomes a 
tamperproof box holding another capability! (nm the surface, this 
makes it appear inevitable for capabilities,to.grow larger and 
larger as objects are extended repeatedly, a prpblem already dis- 
cussed in connection with our first. approach to type extension. 
A carefully designed implementation, however, can avoid this 
phenomenon, allowing unlimited extension with fixed size capabil- 
ities, as we shall see in. section 2.7, which discusses the sealed~ 
capability approach in more detail, First, however, we digress 


_ briefly to examine some more general, questions.about type extension. 


2.6 Hierarchies of Objects, and | 
In a_non-extendible system, only.a small, fixed number of 


predefined. types are provided, hence. types can be. identified by 
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small integers. In an extendible system, a much larger set of 
‘types is needed. Two conflicting considerations influénce the 
choice of the size of this set. On the one hand, it is desirable 
to minimize the size of type identifiers, since these appear in 
capabilities, where compactness is a great vittue. On the other 
hand, it is desirable to maximize thé total number of types 
available, to insure that the supply will never Ga ‘eikhausted: 
especially since type identifiers, like object IDs', can never be 
reused. | 
Emphasizing the first consideration reéults in a system in 
which the number of types, while much larger than the number which 
would ever be legitimately used, ia sttil fairly modest (e.g. thou- 
sande or millions of types) [St 73]. This Iéaves open the possibility 
of a malicious program using up all available types within a few 
minutes of determined computing. ‘Types in such a system must 
therefore be viewed as a finite resource, and must be allocated 
as such. This is possible, but somewhat inconvenient. 
Eaphasizing the provision of ah inexhaustible supply Se types 
results in a system design in which the space of type identifiers, 
like the ‘epece of object IDs, is effectively infinite (f.e. too 
large to be exhausted during the lifetime of the system). By 
combining these two infinite name spacés, the HYDRA syetem [Wu 74, 
Jo 73] provides an elegant conceptual framework in which types are 
themselves objects. This is illustrated in Figure 2.6-1, which 
depicts the set of all objects as fér@ing a-three-level tree. For 
purposes of this figure, only two attributes of @ach object are 


of interest. One is its ID. ‘The other is its typé, which is 
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Figure 2.6-1: Three-level object hierarchy 
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simply the ID of some other object.* ‘Inaieting that the other 
object so identified be of type 'type,' and providing a special 
root-object with ID 'type' (which is giao of type "type') forces | 
all objects (except the root) to occupy either the second or third 
level of the tree. The gaboud"tavel contains the types, while 
the third level contains the non-type objects. 

Creation of objects in guch a scheme can be described concep- 


tually as a single operatioi:: 


c + create object (C ) 


obj type 


where the new object will be @ type ik, Sega ~$8'* capabiiicy 


naming the root object, and @, normal object. aft OC ‘type is a capabil- 


- ity. ‘saning a second level object. Tf a “nange a third level 
object, an error is signalled. ‘In practice; pa ‘course, such a 
unified base-level create object operation cannot replace the 
spect ito: aksectreneatimm mperkt lone fas cebe various oe types, 
since only the cortesponding ayer has. both: the authority and the 
knowledge needed to ‘ereate. and indtdeline el the various eguponsnts 
of the representation of a given cypeof extended~object. 

The practical disadvantage of the viewpoint just described 
is the large disdvok type IDs. heveicialene, we adopt the HYDRA 
view of types as being objects. In Chapter 3, we describe a scheme 
which manages to adopt this point of view, and yet provides an 


extremely compact representation for capabilities. 


There is a second kind of hierarchy among the types in an 


= 
Unique IDs, which are simply long integers, are shown as symbols 
in Pigure 2.6-1 for clarity. 


t 
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extendible system, which has been described by Mors 6 [Mo 72]. 

This second hierarchy involves ais the types, Saehuy than all 

the objects, and attempts to characterize the layered nature of 

the system. Figure 2.6-2 illustrates a simple example, in which 
segments are assumed to be predefined, and various plausible 
extended types are shown, each indicating the type of its imple- 
mentation. This assumes that ail\objects of a given extended type 
have the same type of representstion, which does not seem unreasonable. 
One can find ciesree,, however, af situations in which differing 
characteristics of objects of the same extended type might make 
different types of representations desirable. In Figure 2.6-2, 

for example, . ore might wish to allow: Acee decunents: composed of 

a: collection of text files, which, according to Our Gpasadtiouns 
would be represented by a ‘segnent containing several. text file 
capabilities. As another Neca dade one might jvish te represent a 
customer list as a sorted“fite. or as a Lanked ‘lfst,. depending on 
the frequency of insertions and deletions expected. fn the general 
case then, the types form not a ‘siapie: treé, but a directed graph 
without cycles. The latter igenea srpeanees the partial order 
induced on types by the layered structure oe the system. Note that 
for any given extended object, there is only. one representing 
object, hence for a given representing object, the extended objects 
it represents can form at most a tree. (Of course, in any realistic 


situation, this tree is only a linear chain.) 
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Figure 2.6-2: A type tree 


2.7 Type Extension Using Sealed Capabilities ; 


We now return to the last of our four approaches to the naming 


of extended objects, that using "sealed capabilities." As in the 
sealed-data approach, the manufacture of extended capabilities 
must be carefully controlled to prevent forgery. Given the view 
that types are objects, the appropriate authorization to auaitan’ 
ture a capability of a given type is a capability of that type. 


A layer can obtain a new type T by executing 


C, + create _type ( ) ca 


- Subeequentty, it ‘can seal any capability C by executing 


C, + seal (C,c,) E 


ag illustrated in Figure 2.7-1. °C. will have type T, all privi- 
_ leges on, and a new unique ID aseigned by the systen. 


biter, 30 lcan be recow F by ating" 


C+ apiece ck eee 


' Note that Cy must be presented to authorize unsealing, thus pre- 
venting any random possessor of C. from obtaining the capability’ 
© which ig sealed inside. 

The implementation of capability sealing as just deectitied 
requires a fair amount of machinery, such as that to be described 
in Chapter 3. However, a slightly restricted wari xe capability 
sealing can be added to TCS in a surprisingly simple way. In the 


description below, we assume that a layer wishes to implement 
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Cy + seal (C,C,) 


_— 


Figure 2.7-1: Sealing a capability 
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‘capabilities of type Z suaied inside. 
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extended objects of type T| whose. representations are of type TY. 
The creation’ of type Ty is performed by the operation: 


Sotto ow « 
aa ft 


oy + “erente: type (r, P, ) 3 


a 2 ee 83.4 
: = . 


“Note that the type ‘of the representation a) et be specified. 


cv aie Mee yer Ok ey EEPSE ECE A ane eos oe iypotet 


This is one of the restrictions necessary for the implementation 


E9528 4 


described below, and eorcke ‘the eet of types to form a tree, as 


po Sead 


st goa ebiice v8: i 
discussed in the previous section. - "Klso; a set of privileges (P ) 


oh ay 3 bepiraau 


must be specified, whose eignificance will be expranee below. 


att) Wetaat pie 
The resulting capability for. the new type (c,, ) allows the crea- 


wvad 


Ae se bt E 


tion of new capabilities of type Tas ‘contdining répresentation 


op ghd ge itt oa oe 


‘The creation of an extended ‘obfect savelves, the ‘ereation of 


its representation (which results in a ‘capability c DD followed 
a OGE as tS oi 
by the creation of a capability c "for the extended object, using 
Drs he pag d ders 
the operation: 


Not 


C,. + senl .«C Fs Gy se sae 


rns ear 
BEES, eeeptce ** 


This produces a seeled capability... G_. The. ‘seeand reatriction in 


the. echeme is the requirement thet.C, contain at least: the privi- 


Sy 


_jeges in P. (In -pragtice, thia dang pmpblem, since sealing is 


generally preceded by the, cxeat&on of. the representation, which 
produces a fully privileged capability: €..):. arid aga wie? 

Later, whenever the implementing domain receives as a paca 
meter a capability C. of the new type, it can recover the sealed 


capability C. using the operation: 
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C_ + unseal (C, 40, ) 

Note that the recovered capene ty C. has exactly the privileges 
Pe which cannot be eedter chan the eeieaShans in the capability 

deasamans sealed. Thus, ee feos tai which bondonrnaae the peptes 
“senting ty type need not trust the » Layer Anplamenting rhe extension, 
gince the latter can . only x recover r privileges! which it ae previously. 

. The schene just described can be tnplenented by representing 

. the extended | type as ‘shown in Figure 2. 7-2, Rives implenentation 

of sealing : now ‘consists of merely changing the Sree field of C. 
from T. to a and ts on all ‘privileges to Produce C.» 
while unsealing siuply changes tt back and ante the privileges to 
Py? bess reer oettne. c, agein. _ ote that g, ¢. wil thus contain 


the same object ID a8 did c, 2 rather than a new ik provided. by 


the system. In practice this is nee a serious probles. 


‘This dusicanntacion sieatly aiiow a given jebsect to be extended ~ 


one or more times, and still be cepreadaced by a standard-sized 
capability. Variations on tiis scheme which depend on short type 
IDs are described by Sturgis (St 73] and Lindsay {Li 73]. Another 
_ velated schame.is. the "constituent: rights” ‘approdth disctiseed by 
Jones [Jo 73},).which is eseattiwliy <quivelubt to ‘esdling « segment 
containing seversi capabilities.» Chagter 3 will deserite a acheme 
which ekiminates the: restricttone described ‘above, allowing arbi- 


trary sealing of. capabilities. Fev a Uhags 


8 Fle: 
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Figure 2.7-2: Representation of a type 
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2.8 Goals for a New Capabili ten 
This aheear: has attempted to set the stage for the proposed 

capability mechanism of Chapter 3 by sketching a typical capability 
system, exploring the problems of revocation and type extension in 

the context of that system, and diecidating various relatively minor 
modifications to such a system attempting; to splve those problems. 
In disucssing these modifications separately, examining both their 
strengths and their weaknesses, a number of desirable properties 
have been noted. Thesd are Listed telov,| and are adopted as the 
_ goals to be met by the desiga Proposed’ ini Chapter x 


1) Revocation should take effect immedtarely. 
2) It should be possible to revoke the various privileges. 
in a capability independently. . : 
3) It should be possible to selectively revoke the privi- 
leges of a subset of the capabilities for an object, and 
this should require no global knowledge of capability 
propagation. . 
4) Any distributor of a capability Give. not just the "owner" — 
of the object) should be able to revoke its privileges. 
5) The users of capabilities should net need to distinguish 
between revocable and non-revocable capabilities. | 
6). The cost of revocability should not be excessive. 
7) ‘The mechanisms of revocation snd type extenéion should 


interact correctly. 
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Chapter 3 


A New Capability System 


3.1 A New Capability System 

The goal of this’ chapter is the description of a new capa- 
bility system (calle¢ nes For, SMOEEY i ta meets all of the goals 
listed at the end of Chapter 2. peoaia nes a feirty eubstan- 
tial departure from the tcs system of Chapter 2. After atacusatng 
two abstractions of the “Link sail achaiee of Chapter 2, we 
adopt the family tree model to ‘describe the revocation behavior 
of capabilities, The: echanianf of generalized sealing is then 


proposed, to provide both. revocation and type extension, and the 


practicality of implementing the ‘scheme is argued in some detail. 


3.2 Design Considerations for Revocation ; 
Ta the design of the acs capability acheme presented in this 


‘ cliaptér, we we wish to retain as nknty” ~ XW pobetble of the advantages 


Sa 


of the" indirection scheme of Chapter 2, ng ‘ts pro- 


blens. There are at least two approaches : which can be taken in 
attempting to capture the | essence of the dndirection scheme in a 
base-level construct, as depicted in-Pigure-3: a On the one 
hand, as in Figure 3.2-l1b, one can (ragard 2G, re being merely 


. X. 
a ‘Part of the; mapping from C, to the. object... ea Cc. as peing 


a special revoker capability “it allows that mapping to be broken. 


£ PW ipo ke cage “ i i SRE sg 


On the ether end: as in Figure 3, 2-lc, one can conard both Cc. 


and C, as being capabilities for the object, with C being 


b b 
somehow dependent on Cc. in the sense that revoking Le 
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object 


(a) Indirection scheme 


C 
b 
°° C=};—<> 
r 
object 
(b) Revoker-capability approach (c) Dependent-capability 


approach 


Figure 3.2-1 


automatically revokes C. as well. 

Taking the former point of view results in a scheme ‘in which 
the mapping from a capability to an object is itself viewed as 
being essentially like an object, since one can have a capability 
for it and thus be authorized to manipulate it. To allow indivi- 
dual privileges to be revoked independently, one must define the 
asipide aa csacaiuine: oy at least limiting, the privileges of the 
capability.--The establishing of one's future power to revoke a 
capability should be an atomic operation, es discussed in Section 
2.4. For seigalé. the situation in Figure 3.2-1b ean be produced 


by executing 


C. + revoker (C)) - 


Subsequently, the possessor. of He can revoke the privileges in 


C by executing 


‘revoke (CsPyY Oo. 


In its effect on C this is equivalent to the TCS operation 


b’” 


reduce (Cc, ,P) ‘. 


The difference lies in the fact that, unlike reduction, revocation 
also takes effect in any and all copies of C, which may exist. 
The interaction of revocation with copying is clarified in 


Figure 3.2-2, which shows the situation resulting from executing 
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object 


Figure 3.2-2: Interactions of copying 
and revoker capabilities 
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c+ revoker (C,). 


Cc <«Cc 
x y 


This kind of interaetion causes subsequent revocation of oe to 
affect C, but not C_, which is clearly the desired behavior. 

More complicated situations include "subletting," as shown in 
Figure 3.2-3, in which: hoth the original owner (holding C)) and 
an intermediate distributor. (holding Cc) retain the power of 
revocation over the user (holding C.), and "bill collecting," 
as shown in Figure 3.2-4, in which the ability to revoke the access 
of the user (holding Cc) is delegated toa "collection agency" 
domain, with the owner (holding Cc) retaining the option of later 
disabling the collection agency if the contract with the user is 
renegotiated. Note that the latter example takes advantage of the 
fact that ‘revocability, bedi authorized by a capability, is itself 
thus revocable. “ae F 

The revoker~capability approach jiist described has a good 
deal to recommend it, and has in fact bese explored in some detail 
in a system design seolabts at Stanford Research Institute [Neu 74]. 
However, we pursue here the depandent-capability approach instead. 
Investigation of the ner ooTe ee Ot reveals the following advantages 
of this choice: 

a) It avoids the introduction of special capabilities 

authorizing Sevseatien.rckas simplifying matters some- 
what (although a certain amount of complication is 


unavoidable, as we shall see shortly). 
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Figure 3.2-3: Subletting using revoker capabilities 


object 


Figure 3.2-4: Bill-collecting using revoker capabilities 
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b) It avoids treating the capability-to-object mapping as a 
manipulable object, which significantly ceducen (apie 
mentation costs, but sacrifices the ability to make 
revocability itself revocable. 

ec) = 6It can be cast in terms of a mechanism (to be described 
in Section 3.4) which unifies the notions of revocation 
and type extension. 7 | | 
Tt must be admitted that the chojce {s not entirely clear-cut; in 
particular, the opposite conclusion might be reached in a context 
in which revocable revocability was considered important. 

One motivation for the notion of dependent capabilities is 
the observation that a weakened copy of a particular capability 
can arrive tn. the possession 9 dompin aga, result of either of the 
following sequences of actions: ; . Bere 

4) The privileges in the original capability are reduced 

_ to the desired set, and then a copy is passed to the 

b) A copy is passed to the receiving domain, and then the 
extra privileges are revoked from the original. 

‘The essence of sequence (b) is that the granting domain “has 
second thoughts" and wishes it had uged sequence (a) instead. This 
suggests defining the revoke operation by simply changing the 


reduce operation to be commutative with copying, in the sense that 
revoke (CP); +c, 
and aa 


C. + c.3 revoke (C_,P) 
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‘produce the same net effect. “oF course, revocation cannot be 
expected to undo any intervening exercise of the affected capa- 
bilities hence this commutativity applies only to the state of the 
protection structures, rather than to the atate of the objects 
being protected. Nevertheless, it is an attractive way of describ- 
ing the effect of revocation. i 
Exactly how the revoke operation manages to find all outstand- 
ng copies of the capability being vgboned! 1a be Soiree, the cen- 
tral implementation question concerning this scheme. At this | 
level of discussion, however, we fimpiy imagine that a global 
search is done to locate and revoke the aberdpvidie: cepabilitise. 
Given’ that we require commutativity of copying and revocation 
there are several possible schemes, corresponding to different 
assignments of dependency among the various capabilities existing 
for a given object. Clearly, the com@utativity requirement con~ 
strains the choice to assignments in which the dependency set of 
any given capability includes all other capabilities which have 
been derived from it through one or more levels of copying. We 
examine three schemes, corresponding to three euch assignments. 
Scheme 1: The simplest scheme considers ali capabilities 
for a given object to be interdependent, so that revoking privi-' 
leges from any of the capabilities affects’them all. ‘This approach 
is clearly unsatisfactory in general, for two reasons: 
a) All capabilities for a given object are forced to contain 
the same set of privileges. 
b) Any domain possessing a privilege can revoke it from 


all other domains. 
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Nevertheless, this approach has one virtue which makes it worth 
mentioning: it is possible to copy a capability and have the copy 
retain the revocation powers of the original. This is desirable, 
for example, when a domain simply wishes to move a capability 
within its address space. 

Scheme 2: A more appealing scheme considers the capabilities 
for a given object as forming a "family tree" generated by the 
copy operation as follows: 

a) The initial capability (pteduced at object creation time) 

“occupies | the root node of ; ‘the tree. 
b) whenuier an existiog capability is. copied, the copy occu- . 


% 


pies a new son node of the,‘node conteining the capability 
being copied. a we 
A typical family tree is shown in’ Figure 3.255. By defining a 
capability to be dependent on earh of its ancestors in the family 
tree, we maintain at all times. the. condition that no capability 
can have any privilege not pdssedsed by all of its ancestors. 
Thus, revocation affects entire subtrees of the family tree. 

This tree-structured dependency solves the two problems 
ecccuntered with eékaion 1 above; since it allows different 
capabilities to contain different sets of privileges, and strictly 
circumscribes the effect of revoking privileges from any given 
capability. Thus domain A may pass capabilities to domains B 
and C, such that 

a) B and C have different privileges from each other, 


and from A, 


b) A may revoke the privileges of B and C independently, 


stay 26 
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Figure 3.2-5: A typical family tree of capabilities 
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and c) B and C may not interfere with each other, nor with - 
A, by revoking the privileges. 

Unfortunately, by treating copying in this way, Scheme 2 sacrifices 

the one siyiiivace of Scheme.1: the ability to produce a copy with 

identical revocation powers. A capability cannot be ‘iived by copy~ 

ing it and discarding the original, since the copy, being a son 

of the original would lack the. power of revocation over other 

such sons, and would therefore be an inadequate replacement for 

the original. cage wee 
The probes is caused by two conflicting notions of what 

copying: is ‘for, suggesting that: ‘ewp atttoren} operations are needed. 

Scheme.3 ay combining the ‘eptions, of Scheme 1 and Scheme 2, 
we define a "reduced family tree" of capebihietes ee by a 


eo 


pair of copy ‘operations: ae a 


C. «C) "(as in Scheme 1) -- 
C. + son (c.) (as in Scheme 2) ‘ 


The reduced Faixt ly ‘thee 4s génedated” aa follows: 
a) The initial capability occupies the root node. 
b) The copy operation produces a new capability occupying 
the same node as the capability being copied. 
c) The son operation produces a new capability occupying 
a new son node of the node containing the capability 
being copied. 
. A reduced version of the family tree in Figure 3.2-5 is shown in 
Figure 3.2-6. As in Scheme 2, revocation affects entire subtrees. 


Thus, while Scheme 1 proposed a set of capabilities, and 
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Figure 3.2-6: A reduced family tree 
corresponding to Figure 3.2-5 
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Scheme 2 proposed a tree of capabilities, Scheme 3 proposes a tree 
of sets of capabilities. This is intended to capture the observed 
tendency of the capabilities for a given object-t8 fall natiirelly 
into subsets: containing equivalent’ capabilitfes “(as mentioned’ in 
Chapter. 2). In this scheme, the capabilities in’ each fautiy tree 
node: always contain the same privileges, eitce any chenge’to ‘one 
' of them affects them all. On the ochek-hard, capabilities in’ 
different nodes of the family tree can contwin different’ privileges, 
and ‘ddteract according: 6° the rules of descendant: revocation. This 
contrasts with « system like TCS, in whi¢h any ‘two: capabilities 
may contain different privileges, and reducing the privileges in 
one never affecta the other. | 
One valid complaint about this scheme is that it forces an 
early decision as to which capabilities oné“mdyéventiially wish to 
revoke. The recommended polfey’- would ’be to use @ revocable capa- 
bility whenever there was any doubt concerning’ the trustworthiness 
of a receiving domain. . Indeed, thts is the “fdstification for ‘our 
restriction that capabilities with the same bevowation status may 
not differ in their privileges. It seems intuitively -reasondtle 
that any level of trust less than complete trust may be subject to 
change, especially: since incomplete:trust is often based on incom- 
plete knowledge. —— the same ‘reservetions wittth prompt one to 
pass a capability with restricted privileges stiould prompt” one to 
make that capability revocable. ete ee | 
We wish to adopt the reduced family Stee a6 ‘the modef of - 
revocation behavior in NCS. The implemdntetfon ‘decribed in ~ 


‘Section 3.6 produces exactly this’ behavior, in ‘addition to a ~ 


sealed-capability type-extension sachaniom.: . In fhe implementation, 
‘these two mechanisms. not only interact strongly, but. aleo display 

a. striking similarity, despite. ther, appenentiy, dissied Lar, defini- 
_ tions,. We therefore present, in: Sectdiom 3.4;: a more general: 

: mechanism. vhich subsumes, then. beth... It. ehoudd: be: emphasised. that 
this generalized mechaniem: does. ngt provide. any: additional: privi- 
lege revocation feetures,. but. functions rathec as-an interesting 
descriptive device. unifying two- seemingly different constructs. — 
We will continue. to use. the family. tree-.deseription. as: well, ‘where 


appropriate. 


In the design of NCS, we. wish :te esopt. the: seaied-capability 
approgeh to type. extension, as desexibed in Gbapter 2... The minor 
restrictions in -the TCS. capability sealing wechanion i@f Seetion 2.7 
will be eliminated, but this is not a major-impravesent. What 
is crucial, however, isthe proper interaction of type-extension 
with. revocation. | 

One aspect of such proper interaction hag already been sien- 

tioned; . it met be. possible to-revele gecems to-extendedd objects, 
as. well. as. to, base-lavel objects. Moreover: qual revecation must 
be handled through the normal base~level-revake operation, without, 
for example, any need, to explicitly. notify. the layer. which imple- 
ments the object. that, access is. being yevoked.. Thus ,.no extra bur- 
den is. placed on the user of the: extended abject, although certain 


mild constraints are placed on the implementing layer, as we shall 


all 
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see dn Section 3.5. 

Another snberRceion wate? ‘must be handled | properly is the 
revocation of capabilities ae ebjecte which are representations 
of extended objects. ince ech capabilities < can be, sealed inside 
the extended object capabilities (to any depth), ie revoke opera- 
cia: during its hypothetical global search, mist be a able to look 
inside the exrenees object capabilities and. renove the appropriate 
sriviiexes roe any eligible representation capebilities it finds 
there. This Meas rement rules out ah implementations as that 
described for TCS in Section 2. 7 ia which a cece ed representation 
capability has no explicit existence, but can be peconstructed on 
the basis of core oes Aaa Fhe key assumption being that 

its privileges remain constant, “watch can ne false. face a systes 
providing revocation. The important point bere is ae that a 
layer inplenenting an extended type ‘would ‘normally ‘be. in the posi- 
“Son of having ite representation ‘capabilities revoked, but that 


it must not be possible for the freely available type-extension 


+f 3 


mechanism to be misused to mntde" ‘capabilities from the, revocation 


wechentew: 


3.4 Generalized Sealing 


in discussing capabilities, « we pave: sometimes eetetvel to 
Si icde co 


7 


them as being sp tormatton "sealed in a box." This Sharacteriza- 


tion has been used by Lampson [La 691, Morris [Me 73) and others, 


and Suggests. the lag generalization of Eepestes. sealing, i.e. 


boxes within boxes. We pave already. been one petcuarton in which 
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such a construct was useful: the sealed capability approach to 


type extension. In this section, we Propose a much more general 


capability sealing mechanism for NCS which not “only ‘allows type 


extension without the restrictions imposed in Section 2. 7, but. 
aise provides for revocation which follows the reduced family tree 
discipline of Section 3. 2. | | . 

The ace of sealing information in a bok can have two conse- 
quences: eee | 

a) Reading of the information is prevented.. 

b)- Modification of the information is prevented. 

Morris [Mo 73] has referred to meeting as being transparent if 


only restriction (b) hold, and o opaque if both restrictions (a) 


and (b) hold. We wish to generalize ‘this distinction to allow 


partially opaque sealing of capabilities. This is ‘accomplished 
by using boxes which are sarkiy opaaus eal pancly ransnteies 

The opaque parts of a box have information on them; they cover 

and override the corresponding parts of the capability sealed 
inside. The transparent parts of a box allow the coreasponding 
parts of the capability sealed inside to show through, and to thus 
remain in effect. It is not surprising that this selective "fil- 


tering" action can be used to capture the notion of privilege 


revocation, as we shall see. 


The ability to seal things in hokea-4a carefully controlled, 
as is the ability to unseal boxes and thus gain access to their 
contents. Various kinds of boxes are available; the : sealing and/or 
unsealing of a given kind of box is itself authorized by an appro- 


priately privileged capability for a type. In this scheme, a type 
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is simply a template for aking hokea: As we will shall see, such 
templates, when used 4a a particular way, generate a HYDRA-style 
3-level object hierarchy, but this is not an explicit darieae Cae 
definition of types. The association of boxes with types should 
not be taken as meaning that boxes are themselves objects, which 
they are not. A box is merely the "skin" of a capability, and has 
no independent existence of its oun’ 

The format of boxes is shown in Figure 3.4-l1. A type is just 
a template for making boxes, and a capability is just a box con-~ 
taining something, hence this can also be used as the format of 
types and capabilities. | One can think of ‘the Fields as being 


eee 


written | as. "erit strings" where ‘each digit takes its values from 


=a fees mies tye TIN vate i rp te en 


{0,1 ,transparent}. The ‘flelde a are all familiar from previous dis- 
cussions , vith the exception: oF the _Ncapabtisey-t0" field, This 
field: identifies the capability, and serves ‘6 distinguish it 
(and all copies of it) from other sintlay capabilities, even if 
their type, privileges and objectnJD. fields are the same. This is 
important, for example, during the hypothetical search which per- 
forms revocation of privileges. 

In spite of the alarming size of these capabilities, we con- 
tinue to assume that each addreseable location in memory is capable 
of containing one. At the same time, we will take the apparently 


paradoxical view that each of the four fields in a capability is 


the full size of a data item which could be stored in the same 


location as the entire capability. This kind of behavior should 


come as no surprise in a system which allows capabilities to be 


nested to any depth without increasing in size. 
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object-ID 
Pe als ee ee ee 


Figure 3.4~1: Format of boxes, 
types, and capabilities 
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The seal and unseal operations are fairly simple. Executing 


_ Cg + seal (C,Cq) 


creates capability C, by sealing c in a box specified by the 


) 
template contained in type T, as authorized ‘by the privilege of 


sealing in Cy. “The box ‘produced is a yetbatim copy of the tem- 
plate in cope T, with the exception that the capability-ID and 
object-ID fields, 1f opaque, will: have: the same new unique ID 


written on them. Executing. 


il romana. (ay aia 


FEversen the process by removing one or note boxes from Cy until 
it suceeds: in removing a box whose erp field de opaque. The 
value of tba type field must. match.thag. of. ‘thei template in type T; 
otherwise, an error is signalled and no -value is returned. The 
capability C, must contain the privilege of unsealing. 

Given the Sood gechin tae. warioas kinds of templates can be 
defined, of which we will use three. 

The simplest kind of template is shown in Figure 3.4-2. It 
is completely transparent, and. geierates boxes we will call 
“lockers ," aince their only. function. is..ta. prevent their possessors 
anon modifying their. contente ‘to ‘any ways He particular, lockers 
are used to control revocation; ae-will be Hiscussed in the next 
genious. A eves donkatalas this. template - provided by the system, 
and a capability for the type, eee sealing but not unsealing, 


is publicly available. 
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Figure 3.4-2: A "locker" . 


Figure 3.4-3: A "revoker" 


Dida has J 


avilaee 


se secr: owt 


Figure 3.4-4: An "extender" 
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A slightly more complicated, template..ip. sham 4a.-Figure 3.4-3. 
It is transparent except for an opaque capability-ID field, and 
generates boxes we will call "revokers." . (Becakl. from the defini- 
tion of the seal operation that each new, revoker; wil thus. have 
its own new capability-ID.) As will be seen: in the next section, 
sealing a capability in a revaker. box is equivalent to generating 
a new son-node in the reduced family, tree...A.type containing this 
template is also publicly available for sealing, but, not unsealing. 

The third kind of template. is. shown in Figure 3. A-4. It is 
completely opaque. The value of. the type field is. just the ID 
_of the type containing the template. Boxes: generated by such tem- 
_ plates we will call "extenders." Extendex boxes. provide a sealed- 
capability type extension facility as.described in Chapter..2. 
_ Several types containing. such templates are. predefined by the systen, 
and an operation is provided for.creating more; such typeg.an demand. 
These types are bet made, publicly acceasible. | 

There may be other kinds of templates which would prove 
interesting or useful, but we wil] not. pursue -this here. Instead, 
we turn to the relationship between the sealing eechanien and the ' 
other operations of the base-level system. 

As mentioned previously, the basq-level. operations taking capa~ 
bilities as arguments can be divided into two groups. Most of 
them simply "look at" the capabilities aa the names of objects 
which are their actual argyments.., A few of. them axe directly con- 
cerned with the capabilities themselves. . The treatment, of capa- 
bilities by the former operations is quite, simple: they always 


rely on the external appearance of a capability, regardless of its 
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internal structure of nested boxes. Yor the latter operations, 
the ‘situation ia more complex. 

Im addition to the seal and unseal operations described above, 
- there are four kinds of base-level operations which manipulate 
| capabilities themselves: | 

a) creation of base-—Level objects 

b) copying of capabilities 

¢) erasing (overwriting) of capabilities 

ad) = revocation of privileges 
Each of these is now described tn some detail. 

Creation ef ba#e-level objects sa whut with the capability 
mechanism in two ways. On the one hand, each new object must be 
named by an initial capability which'is to be ‘returned as the 
value of the creation operation. the fabédéatiton “of this capability 
‘ean best be described as the sealing of an empty extender box, 
using a type owned by the base-level éyeten as a ‘template. ‘Thus, 
base-level object creation depatas: ‘ott sealing. — 

| ‘On the othet ‘hand, sealing depends on the previous creation 
‘of types, whitch are base-level objects. Types cortesponding to 
the various base lével objects (séguetits, domains, etc.) are 
created at system initialization timé. At least the “root” type 
(1D = 'type*} must be created “out of thin afr,” and ‘in fact, all 
base-level types are presumably created this way (dithough concep- 
tually, ore ‘can think of the base-level syétem using its own 
- ereaté type ‘operation, whitch would in tuts use the seal operation 
specifying the ‘root type as a teuplate). see 


_- Copying of capabilities is cénceptually simple in this scheme. 


Peo aa RE Sa arate 


The SRESTe capsptlitys including any number of nested boxes, is 
saeoduced exactly, so that thie new capability 3 ig indistinguishable 


from the original. Thus, executing 


«+ ¢ 


L 2 


results in two identical capabilities,” 

The overwriting of a capability with data or with another 
capability is also simple. The overwritten capebility is destroyed, 
with no particular side-effects except for the obvious possibility 
that some previously allowable actions are now forbidden. 

The most complicated speration in this scheme is revocation, 


which is performed by executing 
revoke (C,P) 


which revokes from Cc (and all copies of ¢) any privileges 
which are zero in mask P. The outermost box of C is required 
to be a revoker. . Note that the revoke operation, like the Tcs 
reduce operation, is portrayed as. modifying an existing ere 
rather than producing a new one (cf. seal, unseal).. Generalizing 
the discussions of Sections 3.2 and 3.3, we will hypothesize that 
the underlying capability machinery performs a global search any- 
time an existing capability is modified and reflects the changes 
in all copies of the capability, even those which are sealed in 


nested boxes. * (These copies are easily recognized by their 


In the design being described, this hypothetical | search is exploit- 
ed only by revocation. Section "3:8 will survey some possible ela- 
borations on the design, two of which would also depend on this 
search. At risk of repetition, we again ‘point out ‘that this global 
search is only a descriptive device, and is not actually implemented 
as such. 


wen 


106 


capability-ID fields.) The particular modification performed by 
the revoke operator is che writing of an opaque. o at each posi- 
tion in the privilege field of Cc witch corresponds toa O in 
the mask P. This is oly done, however, if the outermost box of - 
C is a revoker; the revoke operation refuses to write on any 
other kind of box, and aignals an error if this is attempted. 
Osutatiods must also be provided for testing ihe tee of a 
memory location to see whether it contains a capability, and if it 
does, for displaying the various fields of the capability. These 


operations are straightforward and require no detaiied discussion. 


3.5 Examples of Generalized Sealing 
This section outlines some intended uses of the NCS sealing 


mechanism just described, and reviews the goals ‘listed at the end 
of Chapter 2, to assure that they have all been met. The descrip- 


tion of directories and other specific facilities which can be 


. implemented using NCS capability sealing is postponed until 


Chapter 4. 

There is more than one reasonable way to use the NCS sealing 
mechanism for revocation, depending upon the exact situation (i.e. 
the number of domains involved and their relationships to each, 
other). In the example situations below, it is assumed that 


domain A possesses a capability and wishes to pass it to one or 


_ more domains B. In choosing a method of doing this, A controls 


the possibility of later revocation of the various capabilities 


passed. 


To illustrate the various situations, the sealed capabilities 


are shown as arranged in corresponding reduced family trees. Recall 
that sealing a capability in a revoker box corresponds to cenvating 
a new son node in thie ‘tree, 

The simplest situation is. one in which A completely trusts 
B, and simply passes a copy (Cc B of its own capability (Cc, ), as 
shown in Figure 3.571. The moet dmportant example of this is in 
"system calls," in which A regards domain calls on B as being 
operations of its "extended machine." As will be seen in Section 3.6, 
the passing of such peri-sealed, capebstecy parameters represents 
a considerable saving. “This: is ‘very significant, since experience 
suggests that a great aadoriey of domain calls executed are in 
fact system calls [38. Ja sa are also logical reasons for 


REEY, & 


passing non-sealed <apabsidedas’ ig certain kinds of system calis, 


fe Sxtended mechanisms for capability 


awe 


namely those which acd: pare 


storage and/or Certo e such as directories or message 


lgttayn dS. 
parece 4. ‘ 


channels. 
If A does not have complete trust in B, then before pass- 

ing Cc, to B, A ‘shoukt peal. it in a revoker box. By keeping 

one copy (c,) of the owaled éapabilicy, and passing another (c,) 


to B, A retains the.pover of later revoking B's privileges. 


set saa 
domains ee sn would. be the creation of 


C, as above by mualing dn p-tevorer, followed by the passing 


Ese ae. 


of n_ copies of Cc. (denoted Cc, ). to the domains 8B as 


i’ 
ay 
' shown. in Figure 3.5-3.. Qlote that thie 4s juat. the,eieuation 
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which would arise if A passed Cc, to Bi» and Bi» 
1 


trusting Bo '* BL in turn passed copies to them.) There are two 


completely 


limitations to this use of the mechanism. One is the non-selectivity 
of A's power of revocation; revoking privileges from any of the 
domains B. requires revoking from all of them. The other limita- 
tion is the lack of isolation between the domains Bi 
them is capable of revoking the privileges of all of them, which 


any of 


may be inappropriate. 
Both of these limitations can be avoided by simply handling 


each of the domains B, separately as in Figure 3.5-4. This 


allows selective revocation from each of the B and isolates 


i? 


them from each other in case they are mutually suspicious. For 


example, the various By may be the renters of a program owned 


by A, in which case both of these considerations are important. 
On the other hand, there are situations in which A _ does 


not need to revoke the privileges of the various B, selectively, 


but does wish to isolate them from each other. For example, a 
professor may wish to grant access to a grading program to all of 
the students in his class. He certainly wishes to prevent the 
students from revoking this privilege from each other, but may 
well have no desire to revoke their privileges independently, 
especially since this is somewhat costly and requires that A 


retain and use n different capabilities C. . In this situation, 
i 
A can produce a single CR by sealing Cy in a revoker box, and 


can then distribute the capabilities Cc. produced by in turn 
i 
sealing Cc. in a locker box, as shown in Figure 3.5-5. This not 


only eases simultaneous revocation, but is significantly cheaper, 
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Figure 3.5-4: Pasging independently. 
revocable capabilities 


ca) 


Figure 3.5-5: Passing isolated | 
_ simultaneously: reavgcable capabdiities - 
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given the implementation to be descesbed, ia 

Fron this discussion, it should be clear that goals 2, 3, 4 
"and 5 of Séction 2.8’ are satisfied by the proposed design. Goal 6, 
that of ‘téasonable cost, will be treated in the next section, _ 
. which pfoposea ‘an implementation for sealed capabilities and dis- 
cusses its efficiency. This léaveé’ only goal “1; "that of ‘inmediate 
revocation, and goal 7, that of proper intetaet ion’ between revo- 
cation and type extension. Between them, ‘chee’ ‘tbo goalé: ‘generate 
one fairly subtle problem, which mist be diseased before all the 
goals can be considered satisfied.” | , 

It ‘fa ‘clear that revocation as defined takes effect inmediately 
in the sense that the privileges of the appropriate capabilities 
are immediately tiodified. This is only significant, however, to 
the extent that the corresponding ‘operations’ on the object’ in ques- 
tion are immediately prohibited, wiiich in ‘tuiy dégende én the 
checking of the privileges by the opératiéng. * One can imagine the 
following kind of scenario, in which revocation is effectively 
delayed: ee a ddeiata: A in process Py passes to domain 
B in process PS a capability to access X, which is an extended. 
object implemented by layer L. Suppose that layer L is repre- 
gented by domain L, in P, and by domain L, in P,. Assuming | 
that we can say nothing about the relative execution speeds of Pa 
and PB [Di 68] the sequence shown in Figure 3.5-6 is one possible 
outcome, and produces an effective delay in revocation which is 
visible to A. Strictly speaking, the problem here is caused by 
the occurrence of step Al between steps B2 and B3, which should be 


executed together as a “critical section." Synchronization between 


Al. 


A2. 


A3. 


A4. 


AS. 


in P 
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Bl. 


B2. 


A revokes B's privilege 


to modify X 


A calls Ly to examine X 


Ly returns to A the 


original state of X 


B3. 


A calls L, to examine X 


A 


Ly returns to A the 


modified state of X 


Figure 3.5-6 


in PR 


B calls L, to modify X 


L, verifies that Bis 


authorized to modify X 


L, performs the previously 


checked modification of X 


and returns to B 


mn Peg SOOM ate ae tee re pe fae oo ee 


the baweclevel system and renee layers - freugnt with difficulties, 


however, hence the following: alternative seens preferable: when a 


. layer ‘ie about to access the representation ‘of an ‘object, it must 


ag gee 


first lock all ‘parts of the representation to be touched and then 
check to see that the requested operation te “authoetead, In many 


Cases, this ‘interlocking would be necessary anyway; the major 


; change due to revocation. is the. moving of privilege checking inside 


of the critical section. ‘(a particular this means ‘that pre~check- 
ing of privileges as an integral part “of the doeain call machinery 


[St 73, Wu 74] is not very useful in a syaten ja. which ‘privileses 


Gs w 


yah 


are revocable. > 


“In the context of Figure 3.5-6, such checking would delay 


step A3 until after step B3. The ‘crucial point ‘de ‘that this 


renders the situation ‘indtocinguiahabie™ “fron < one in ‘whieh step B3 


 ecetrred before ‘Al. Thus, although an acceas may occur "slightly 


- after permission’ to perform it “has deen ‘revoked, “there is no way 


for a ‘properly ‘written (i. — “tining independent) program | to detect 


Sad 


this occurrence. 


3.6 Implementation of Generalized Sealey in NCS 


‘As in previous "atediasiona, we begia by describing the repre- 
sentations of capabilities thenselves. 1 A tagged memory ‘location 
holding a ‘capability appears to “the user ‘to contain @ a “rather large 


amount of ‘Information, ‘but in dctuaiity Ea contains « a “short form 


“except: for real-time delays. 
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of the capability, consisting of a "locker bit'# and the ID of the 
capability as shown in Figure 3-6-1. The other fields are stored 
elsewhere, and the ID is sufficient to locate them, allowing recon- 
struction of the complete Jong form of the. capability. - 

| The most important advantage of this approach is that it 
allows the changeable information (e.g. revocable privileges) in 
all copies of a capsbility to be centralized and thus updated 
without a global search. anes is crucial to, the. practicality of 
the acheue , and will be discussed in. more detail shortly. 

This approach also allows the effectiye storage of an entire 
capability in a single practical-gized word of a tagged memory. . 
, For example, on the terribly pessimistic assumption that a new 
: uni que ID is generated every. 10 ‘aleroseconds, the uge of 48 bit 
words would allow the systen to run, pontjagously. for. about a cen- 
eury without exhausting ite Supply of names. Using a name-space 


compaction approach and a somewhat more Tealistic. level af pessi- 


mism would probably allow the use of 32 bit words without requiring 


an objectionable frequency of system siceiocai to perform the 
congactican (i.e. once every few weeks or months, at worst). 
An attractive way to store Sbe ‘boxas sbAch. constitute the 
actual substance oF the capabilities, would be. dn a global hash 
table Contesning small fixed sized entries and keyed on unique IDs. 
The map , as described in Section 2. 2, is just such! a atructure, 
which cuggests implenenting each | box as a map entry. This approach 
yields an integrated structure for the reconstruction and inter- 


pretation of nested capabilities from their short. forms. The 


“This is not the same as the tag bit on the capabdlity, and will | 
be discussed below. 
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locker bit 


capability capability-ID ia 


(short form) 


Figure 3.6-1: Format of (short-form) 
capabilities and map entries 
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increase in size and complexity of the map machinery, while non- 
negligible, is not excessive. 

The format of a map entry is shown in Figure 3.6-l. The 
capability-ID, type and privileges fields of the corresponding 
box aré represented directly, while the object-ID field is replaced 
by a new "contents" field which serves to locate the contents of 
the box. Map entries for various particular kinds of boxes are 
shown in Figure 3.6-2. 

Base level capabilities, while conceptually the same as other 
extenders, are represented in a special form. The contents field 
contains the physical address of the object, hence these map 
entries correspond to the map entries in a ponrne like TCS. The 
privilege field would always contain all 1's since revocation 
does not operate on extender boxes, hence its value can be implicit; 
the space in the map entry is used to record the size of the base- 
level object instead. 

Normal (i.e. user created) extender boxes are represented 
similarly, but their contents are capabilities, rather than physical 
addresses, and they make no use of their privilege fields. 

Revoker boxes represent their transparent type and privilege 
fields as all 1's. In the case of the type field, this value is 
a constant which is specially recognized by the capability recon- 
struction machinery. In the case of the privilege field, it is 
used as a mask, hence any 0's written in it are effectively opaque, 
as required for revocation. 

Note that no map entry format is described for locker boxes. 


Locker boxes are so simple that they may be implemented in a much 
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Initial capability 
for base~-level 
object 
(special extender) 


address 


iat ees 
| 
Revoker. 


Figure 3.6-2: Map entries 
representing various kinds of boxes 


Cap 


. Type 
Priv 


cont 


Cap 


. Type 


Priv 


Cont 


Cap 


Type 


Priv 


Cont 
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cheaper way. As shown tn Figure 3.6-1, a single locker-bit in the 
. short form capability, rather than a complete map entry, serves to 
indicate the presence of one or more focker. boxes. - (Since they 
are transparent and non-removable, multiple consecutive locker 
boxes are indistinguishable from a single one.) 

Given the described representations of the various kinds of 
boxes, the seal and unseal operations may be implemented as shown 
in Figures 3.6-3 and 3.6-4, reapectively. The eee] operation 
. creates a new map-entry representing the new box and stores in its 
contents field the capability being. odaied. __ Sealing in a locker 
‘bok ie handled specially by simply turning on the locker bit in 
the sealed capability. The onseal wperation simply returns the 
contents of the appropriate extender box. (Recall that revokers 
and lockers can never be unsealed.) Figure 3.6-5 summarizes the 
various low-level -facilities used in A ioe dascript ios of these and 
other operations. These are assumed tb be cleay from previous. 
discussions, with the exception of capability teconstruction 

"Recap" y and ‘associative memory ‘Toskiip ("Cap _: find" and "Cont_find") 
which will be described” shortly. a 

The creation of. each. naw baserievel object includes the 
construction of the "root" map aatty: representing its initial 
capability. This map-entry is self sufficient, in the sense that 
it does not depend on aay other map entry for its proper interpre- 
tation. ‘On the other hand, a map entry representing a revoker or 
extender box contains another capability; its one-word contents. 
field holds the short form of the capability, hence its interpre- 


tation is dependent upon the other map entry holding the rest of 
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‘Locker(c.) + If” 


pete ET 


om 


Type M) ‘at. ek 


Priv(M)°# 41...12 


2. 
Cap(c_) « I 
Locker (c_) «0 


Figure 3.6-3: NCS seal operation 
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C. + unseal (¢,C,) 


Return Cont (C) 


Figure 3.64: NCS unseal operation 
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y 
Fields in various ete etruerures (see also poreeapones te figures) 
| Cap (x) | | . | capebtlicy-1D (ay 
Type (x) | . type v1 Pie: . 
Priv (x) | | privileges: | 
“Obj (x) | - object-1D_ | 
Size (x) size 
Cont (x) _ cgatedte 
Unique names 
-New ID (¢) 7 generates’ a hew nique: 1D 
- New_map entry oO | creates ‘map entry jae b capability-ID= I 
| Map entry (1) | finds ap entry w with capability-1D= 1 


Delete map entry (™) deletes map entry M 


‘Capability reconstruction - 


“Recap (c) = reconstructs ‘long form of ¢ 


Associative memory 


cap_ find (I) find ais with capability-10 = I 
o ebee LRU entryy 
Cont_find (x) find entry with contents = x 


(else: TRU entey)i “33 


Figure 3,6-5 _ Low level facilities used by operations 


ity ines 
aod aia 
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that capability. ‘Thus, repeated seating we a 1 base-level object 
results in the generation ‘of a@ tree of map entries, which combines 
the functions of the type tree of Section 2. 6 and the reduced 
family tree of Section 3. 2. An example of mech a tree is shown in 
Figure 3. 6-6, in which : a saguent is used as the representation of 
an extended object of renee ‘directory,’ for which various capabilities 
have been distributed. pe 

It is important to note that while the senk.operation 
generates euch tree. structures, the unseal opeamtion does not dis- 
mantle them. For example, in Figure 3.6-6, if the layer tapes 
menting directories unseals C, to obtain Cy, . the map ‘atructure 
‘rensine unchanged, “The mechanien for deletion of unneeded map | 


Soh ebe 


entries will be discussed later. 


a 


In cae <s reconstruct the joke fore of a capability, it is 
with the 


' necessary to examine the boxes wiskeh: somone: Af 3 Bi 


outermoat: and. working: jaward, until all fields: are: guapletely opaque. 
Given the particular kinds of boxes mont in our acheme, this simply 


fy 


entails mcumoies at a chain of (zero or more) ravokers until a 


non-revoker boss. is. pncouatered . This reconstruction procedure, 
shown in Figure. 3.6-7,. > ie rather similar to the “following” proce- 
dure for. indirection chains of Section 2. 4. 18 other figures, the 


s §yog wrk 


capability. reconstruction procedure is referred to fe the form 
C + Recap (c) 


where c denotes the short form and C the reconstructed long 
form of the capability. In addition to the visible long form, the 


reconstruction process also recovers the represengation pointer 
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Capabilities: 


Objects: 


Figure 3.6-6: A map entry tree 
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C + Recap(c) 


I+ cap(Cont (M)) 
P+ PA PrivQiy.” 


iv(a) +P 
“Obs (a) + Cap{M) 
alA) + Priv(M) 
ont(A) + Cone (Mf) 


EXIT 


Figure 3.6-7: Capability reconstruction 


scoala = At aS a at a 


‘from the capability to the object, which consists of the short form 


representation capability in the case of extended objects, and 

the address and size for base-level objects. Thus, the result of 

the reconstruction process is a mapping, as shown in Figure 3.6-8. 
The cost of the reconstruction process is relatively high, 


since it involves scanning a chain of map entries, each of which \ 


mast: be located-by hashing “inte the map. The retention of the most 


‘active’ mappings tn fase hardwage thus becomes even more important 


‘ “than in a ‘ayeten “Iitke TCs. “The adsoctative' memory discussed in 


Section z. z could. be used. withbut change to hold map entries from 


“active chains: and thus ‘speed up the scan. nial the other hand, a 


~ "50% increase in fhe size of the eect tice ass entries allows 


“them to contain entire mappings, gave: than single Nei enteree: 


f 


On fhe average, this modification would probably not provide a very 


sg 


: omeria: improvement. in. speak hey. “prpeaning: the. geconstruction 


process entirely, rather than merely accelerating it) and might 
even slightly ‘reduce the. aéfictency. of: spase utilization in the 
associative memory (if the average chain length was less than 1.5 
map entries). It is desirable, however, since it allows a fixed 
amount of associative memory space to effectively contain a chain 
of arbitrary length, thus preventing long chains from severely 
degrading performance by filling up the associative memory. We 
therefore specify the associative memory as containing the several 
most recently used complete mappings. The exact number to be 
retained would depend on several considerations, ranging from 
available hardware components to expected usage patterns. Two 


factors which favor maximizing the number are the relatively high 
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Capability 


Representation 
pointer) 


® pase Deve! objects only 
ae padrese if base-Ievel object: 
Representation capability (short form) + exteited object 


Figure 3.6-8: i hiealoa 
(ae stored in the assoc tative semory) | 
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cost of initial soacing (= Gapaviltey reconstruction) and the fact 
that the vetained mappings ressin valid through aoea innate and 
process switching. 

In the various figures, the © associative menory facilities are 


represented in the form: 


A + Cap, find (x). 


A+ Cont find {K). 


Each of these finds an associative memory SAEEY whose appropriate 
field (capabiltey-1 or contents) ‘contains he value X. If no 
such aut. is. present, the laest recently used JSneey is found. 

> ‘The revoke operation is quite straightforverd an terms of 


its | effect on 1 the: map. Since all copies of a given revoker box 


are represented by a singe map entry, the masking of the privilege 


field of that map entry lemseuanmcans revokes ene corresponding 


privileges from all the copies, including those de ogee inside 


ha 


other capabilities. The only Problem is that Soha’ of Shese: latter 


capabilities may already have been reconstructed and saved in the 


guecciative memory, necessitating their removal. 

Unfortunately, the names oF all such capabilities cannot be 
determined from che. name of the capability being revoked, _ except 
by duh codieide a san tinatal and fragile backpointer structure 


into the ee One had oF dealing with this problem is 


ote coupiacely ‘flush che associative mmory: on: each Pexoratron: 


: This: will: be satisfactory if: the: ‘Frequency of evocation’ is rela- 


‘gas 


tively Jew. If revocation: 4s a uftictentty frequent. ‘occurrence, 


however, this wilt drastieaily reduce thes a aetitey: of the associative 
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_ memory by forcing neEYy use of the expensive reloading procedure: 
A quite satisfactory conscoulee between total flushing of the > 
associative memory and selective emore’ of only the affected 3 
capabilities is the removal of all capabilities for the same ' 
object. This is easily accimp lished using the "Cont find" feature 
of the associative memory, as shown in Figure 3.6-9. (Por sim- 
plicity, we have assumed that 0: is not a valid value of the 'Cap 
or Cont fields of a mapping, and can cherefore be used to disable 
an associative memory entry. ) This seni-selective removal will 
sometines force unnecessary reloading of capabilities which were 
not affected by the revocation, but thie will only ‘happen when a 
capability is revoked and another ‘capability for the same object 


+ 


which is not its descendant in the tantly tree appears in the 
associative memory.* | ° . . 

‘The storage of inactive map entries in secondary memory is 
much the seme in NCS” as in TCS. Bach rcs map entry corresponds to 
a " complete tree in NCS, but only the active ‘patho in the compiace 
tree need be kept in EriBary memory. Tt seems Likely that, known 
techniques for localizing list structures o ‘secondary memory t 


[Bo 67] could contribute significantly to nininieing the overhead 


incurred when an inactive Pach becomes sctive and wust be brought 


into primary acy. 


*one possible frequent example of this would be revocation of a 
domain-call. parameter upon xeturn:. from the tall, -Rewotation of 
the calle's capability would unnecessarily remove the caller's own 
capability from the .associasive. seuory,. Thée couli: ‘pez avoided us- 
ing a modification suggested by Peter Bishop of M,1.T., in which 
the mapping. produced by. the, capability reconstrucefion|mechaniom 
would include the length of the chain scanned to produce it. By 
comparing this value for the. capsbidity being: revoked. and: the 
capability being removed from the associative newiory, one could 
avoid removing tree-ancestors of the revoked capability. 


3 
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: revoke(C,P ). 


ian + - Priv(W A P. 


- ere ASE ted ee ES 


Cap (A) = 0 
Cont (AY = 0 


inst 


Figure 3.6-9: NCS revoke operation _ 
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3.7 Some Implementation Details 


In describing an implemented system, it is often desirable 
to omit or simplify certain details which, while necessary in the 
implementation, are of itech intrinsic interest, and tend to 2 
obscure the significant principles of the design. Unfortunately, 
in arguing the practicality of an unimplemented system like NCS, 
one is obliged to address such issues. - Trts- section is involved 
with auch details relating to the maintenance of the system data 
structure we have called the map. Readers. who: find thenselves' 
growing boreé with the arguments can skip the teasinder of this 
section without significant loss of continuity. | . 

The basic problem with the map as described thus far is the 
lack of any mechanion to ) keep de from filling up. For example, 
by repeatedly sealing a single capability at the relatively modest 
average rate of once per millisecond, a malicious domain could: 
£111 up a 1 million word map in a few minutes. — In a system like 
TCS in which eséh cad entry corresponds to a different object, fone 
might be able to depend on the limitation of other resource usage 
for the object to limit. usage of the mapvepace. reagurce and pre- 
vent its exhaustion. This is clearly mot the case in the new . 
scheme, in which creation of map entries does net imply any other 
resource waage at all. | as =o | ss ne 

For this reason, it is necessary to treat map entries as an 
allocatable resource and thus limit the emount of tiep space 
available to each domain via its account. An account's reserve 
of available map space must be decremented each time a domain it 


funds creates a map entry, and incremented when the map entry is 


POR TERI OES 
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deleted. This a eat ener reach mee entey contain an extra field 


> Uy Teaos 


specltsing te. accoune which ‘funds it siace this may not be evident 


: ea he a ; 
woayng ef bie: ' Buh. uct é 


at EBS tine at which ae is deleted. “Since unused =P space resides 


i 


feb? ars 


pe 


on  eecondaey: atorane, ‘e is quite inexpensive, hence the allocation 


given to each account can ES sufficiently generous that no reasonable 
cose acum ¢ ae waged: onus apa) Pox uunlsie 


"Program mote ever. "exhaust te The limit serves naan to contain 


* SY BEER ed (pa gtoiditae > .omte fs 


the damage dons by pathological to aca 
att Boi oh Las: rCamee aes SP Mite ae 
From the system’ 8 point oF view, ‘the ‘problen : te now “solved 


Bee 2 we gprs aii Wy aa , eae LE Ras & $3 Be 


since each user can hare only himself by extravagant use of mae 
¥ ea Go Bic eBRoe 16; i 
space. ‘This is not really sufficient however ; Ehe oe of 


Bogs peg ee ERs ah 


* gyesc . 2 SaaS yee Be Pires 
such celf-inflicted | hara must not be too severe. A given. account 's 


PP as | é Ld tte 73 PUBS lex ES ae) s? 


‘allocation of map space can be cluttered by an -undebugged program, 


4 gi Ba Lait 3 bE: ue 
“hence some mechanian must be Provided for prevention of and/or 


+ iy 


elergis goniwRe YES Thee & Pretty ¢ GES 


z t oh met - ma ra 
eit becckivi ob gard. | Le *o eeev Bb vadt anisscc5 


ESCOeeLy feos Buchs a | situation. Prevention cannot reasonably be 


ae cS bON ESE 5 ae tadas Br Bas aa ‘ 755 ty Eek ge tuepet 


expected of the base-level systen, since ns cannot distinguish 


mils $ak H Ca aay oe op d- FSL3h aH? : det: Bia 


"between “Legitimate and ‘tLlegitteate use of map space, hence recovery 


i: 


€ 


bi ces SHES DP trek 3 pe ALDLAE Ube 


. acer be SGenible:. We ak the point of view, hoover: that this 


recovery need not be particularly easy or or Liieetal siace, as 

ie Se Gal euvtede Bebo goa kh’ sie ane, 
mentioned previously, most use “af pe sealing sechanien 1s expected 
to ‘be nite mis more civilized facilities rather than directly. The 
arewee of such facilities vill be discussed in some detail 
te Chapter 4, Ar thts point ve are only concerned that such. faci-~ 
litiee ke in de orderly way. wise ew - 

What const ieutes orderly use of the sealing machanion? So 
fer, no ) method has besa: described’ for renoving unneeded map entries, 

Wolo @tG i oa De A nh! GD EAR. fos 


“hence any | use of Memeyai ine ricararaes fill up the Bap: The 


? iat a PQ bah wee teh a fe. ‘ 


“basic question ie: when ees a map inetd no ) longer needed? There 


thoeath wee obaaeu pide, sett 
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are at least two circumstances in which ‘this ts true: 
ay | Its praviiené field is eupty. at . “ ! 
b) Its. contents field points to a non-existent = entry 
or object. | I 
If either of these conditions holds, ans map entry ct Mestese and 
may be deleted. Condition (a) suggents che revoke operation, upon 
reducing the privileges in a map entry, should check whether any 
privileges remain, and if not, “delete the entry froe the map. ‘ Con- 
dition (b) suggests that the capability reconstruction ‘mechanism, | 
upon encountering a map entry whose contents ‘field contains such 
a "dead-end" capability (wnteh we will call an "teolated” entry) 
‘should delete it from the sey a mp » entry whose contents field 
contains the addreas of a base ‘level object. ts deieted ‘when the 
object is deleted, Shae isolating any map entries pointing to it. 
| In general, the seletion of a ee al eatry cam cause oF one el more 
| other map entries to become Leolated, and chee be donated ‘the next 
time they are exercised by the reconstruct ion process. Im this 
way, entire teolated subtrees can he gradually elininated. (The 
case in which euels entries are never subsequently exerctoad will 
be aiecussed shortly. ) 
| Thue, im addition te its noreel cleaning-wp activities 
(destroying unneeded objects, ete.),, * sat anhewed domais should 
revoke any unneeded capabilities: to clean rs ‘the =p. t 
| Similarly, the problen of cleaning up after the ‘execution, of 
an undebugged ‘demain involves deletion of unneeded objects and. “map 
entries, followed by deletion of the domain treet, Problens can 
arise if the faulty domain has discavend all capabilities for any. 
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such object or map entry, which is then lost. A feature solving 
the lost object problem will be described in Chapter a but it 
would be expensive and cumbersome if sised: for every map “entiye We 
therefore allow map entries to become lost and require that recov- 
ery from this situation be FOSStDEe This Eeautree the revocation 
of all capebthries originally conead to the fauley domain, thus 
isolating the subtress of map entries produced by its execution. 
The lost map entries in these ‘trees will never be exercised, how- | 
ever, since by definition there are no > capabilities for then. 

For the reason just cited, gome mechanism must be provided to 
exercise lost map entries. Maceneae: ‘even f for map ‘eatrien which 
are isolated but not lost, it would be helpeul if their eLimina- 
tion from the map was ‘automatic, ieince it may be some time before 
they are exercised. ‘This can be accomplished by anc tag to the 


base-level avatem, a relatively simple operation of the form: 


exercige (I) 


which sinply exercises the I-th map entry by reconstructing its 
capability. A low-priority peace process (sonet ines ‘called a 
"daemon" “phantom") can now be constvucted which uses the new 
operation to ay sweep through the map eliminating ieokated map 
entries. The rate at which this is done is a tradeoff betvecr 
minimizing the extra load imposed on “the map - machinery and maxi- 
mizing ‘the rate at which map apace eis recovered. Given generous 
‘aldecations of map space to ‘the various accounts, the rate could 


probably be quite low. The giercise operation is not available 


to the users, since they have no use for it, “but it is not at all 
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dangerous, hence the background process need not be trusted by 


the base level system. 


3.8 Possible Elaborations on the Design 


There are several directions in which NCS as described in 
this chapter could be elaborated. We here digress briefly to dis- 
cuss four examples, arranged in order of increasing difficulty 
of adding them to the implementation described. 

A simple feature which might well be included in an actual 
system allows examination of the relationship of two capabilities, 
to determine if one is a descendant of the other in the same map 
tree. This would be useful: 

a) To determine revocability of one capability by another. 

b) To determine accountability for unauthorized distribu- 

tion of a capability. 
This checking could easily be provided by an operation which simply 
scanned from the first capability's map entry to the root (base- 
level object) entry of the tree, watching for the second capability's 
map entry. 

Another feature, which has been mentioned previously, would 
be the definition of other useful kinds of boxes in which to seal 
capabilities. For example, a box in which two or more capabilities 
could be sealed would eliminate the need for a small segment to 
act as the root of a compound representation of an extended object. 
This is similar to the scheme used in the HYDRA system [Wu 74]. 


On the other hand, its implementation would require variable-sized 
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map entries, thus significantly complicating the implementation of 
the map. 

A third rather interesting possibility is based on the obser- 
vation that the masking of privileges by the revoke operation is 
not an intrinsically irreversible process. One could just as easily 
provide an "unrevoke" operation for restoring previously revoked 
privileges. Note that in this context, the use of iectex boxes 
takes on a new significance, since it not only prevents inter-user 
interference, but also prevents the possessor of a capability from 
restoring privileges which have been revoked from it. The only 
major implementation difficulty with this feature is the impossi- 
bility of automatically deleting taqtally revoked entries from the 
map, since they may later have their privileges restored. This 
would require explicit deletions of map entries, making the appear- 
ance of the mechanism more complex. In addition, the whole notion 
of unrevoking privileges cannot be described cleanly in terms of 
the family tree model. Nevertheless, this feature could be quite 
useful, since it allows increased levels of trust between domains 
without necessitating the inconvenient repetition of the capability 
distribution procedure. The whole notion of temporary revocation 
could be quite useful, for example, in the debugging of locking 
protocols in a complex multi~process data-base systen. 

The fourth possibility is similar to the previous one in the 
sense that it attempts to preserve an established pattern of dis- 
tributed capabilities while changing the meaning of those capabil- 
ities. In this case, the change is to allow switching of the con- 


tents of an extender box. This would enable a layer implementing 
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an extended object to dynamically change the identity of its repre- _ 
sentation. Of course, care must be taken to avoid the possibility 
of circularities in the map; this can easily be done by using the 
first extension mentioned above to detect the case in which the 
new representation is a descendant of the extender which is being 
modified and signal an error. 

The extensions described in this section could be added to 
NCS without excessive difficulty, but for the sake of clarity, the 
remainder of this thesis will assume that only the mechanisms ori- 
ginally described in Section 3.4 are provided. The facilities 
described in Chapter 4 would require some modification if any or 


all of the extensions were in fact included. 
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Chapter 4 
Two Facilities Using the New Capability System 


4.1 Possible Facilities Using Generalized Sealin 


The purpose of this chapter ia: to briefly explore: two examples 
of helpful facilities which can ‘be constructed: using the: NCS 
generalized sealing mechanism described: in: Chapter 3. One is an 
improvement to the base-level domadn-call machinery: providing 
selective revocation of capability parameters: passed on a call 
when. the. corresponding. return oceurs. ~The other dis an extension 
providing. a new. type of. object: called: @: directory; which: allows 
storage and distribation of capabilities ima manner. which is often 
 tuch more convenient than that. provided. by the: base-level systen. 

. Other useful facilities could also: be:defined: in a similar 
fashion. Plausible exemples might include: |» 
| a) An interprocess communication facility providing extended 
objects called message, channels, capable: of transmitting 
messages containing tapabilities: valid aaly until the 
next message is received. .- | 
b) A rental mediation service, guaranteeing to the lessor 
that privileges. will be: revoked -apon: contract expiration, 
“and to the lesesee: that. revocation eannot occur before . 
. that time. 
These. and other possibilities will: be left: unexplored here. The 
point is simply that the nested: capability scheme: aliows the 
construction of an. open-ended: set: of::extenadons,::nany)of:which can 
also make use: of the revocation properties provided... . 


ad 


1 Seer se 
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4.2 Revocable Parameters 

There ace éatteis events which constitute natural points at 
which to distribute and revoke capabilities, The most obvious 
examples are the occurrence of a domain-cali and the subsequent 
corresponding return. As discussed by Schroeder [Sc 72], the 
temporary granting of access to cavuiter objects: is a natural 
and useful feature of calls between mutually suspicious domains. 
There are other situations, however, in which it is unnecessary 
or even inappropriate to revoke ail capebility parameters when a 
return occurs. in particular, as previously noted, calls to trusted 
machine-extension domains need not revoke their parameters, which . 
can result in substantial savings. We therefore propose a more _ 
general mechanism in which the caller oan specify, for each para- 
meter passed, whether it is to be revoked: when the called domain 

- returns. : 

It would probably be. possible to: provide this improved Amat 
call as an extension rather than an iategral pert of the base- 
level systen. This would require that. all domain-calls and returns 
(or at least all these which involved any. xevecable capability 
parameters) be routed through this extension, which would be both 
clumsy and eostly. We therefore describe revocable parameters as 
being included in the base-level domain~call mechanian. 7 

In the ‘previous discussion of parameter pessing in Chapter 2, 
we found it unnecessary to specify the details of the copying of 
capabilities from the caller's address space to the caliee's 
address space. In discussing the modifications necessary: to wee 


vide revocable parameters, we continue in the same fashion, 


describing the implementation of parameter passing in terms of the 


get_parameter and put parameter operations used in the discussion 
of TCS in Section 2.2. 


When a domain call occurs, the caller controls parameter , 


. revocation by passing a Boolean. vector R as an extra parameter, 


ee 


each element of which specifiqs anether the catpaspoadine parameter 


should be revoked upon re ‘The call thus has the form: 


Call (qe? 


1” 2° eae ad 


_ where B[i] eer of Pie 


Revocation of parameters ‘is implemented using the same push- 
down stack which ‘saves the return gate used to reactivate the call- 
ing domain when the. callee .retpyns. Thus, instead of just a gate 


capability, each domain-call coftresponds to a packet of information 


“as shown in Figure 4.2-1. The first item is N,» which is the 


number of capability parameters to be revokedand the last item 


is the return gate. Between them are the Np capabilities which 


will be revoked when the return occurs. Figure 4.2-2 depicts the 
domain-call operation, and resembles Figure 2.2-2 which shows the 
TCS version. The differences comprise the steps necessary to save 
the extra information in the stack. Each revocable capability 
parameter is sealed in a revoker box; one copy of the sealed capa- 
bility C is passed to the callee, and another is retained in the 
stack: The discipline followed is thus that of Figure 3.5-2; seal-— 
ing of the callee's parameter in a locker is not necessary, since 
it is not received by any other domain. Figure 4.2-3 depicts the 


domain-return operation, as compared with the TCS version in 
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Top of stack 


Information for 
one call 


te ( ) 


Sod da ot Ser 


Figure 4.2+1: Parameter. revocation data in stack 


Lore ates 
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call(c »R) 


ria ae iad 


~ Pash (G,) 


weit 


R + get_paraneter (N,,Caller) 


“a My #0 


Yes 


eos ‘push (Np : 
—<Ag Cy, + eet opareme ce cette 


{ EXIT thru G 


sme oS Be a 


put_parameter(I,Callee,P) 


C + seal(P,C ) 
phe revoker 
put. parameter (1,Callee,C) 
push(C) 
N, oa N,t1 


Figure 4.2-2: NCS domain-call operation 
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return( ) 


ENTER 


C « pop( ) 
revoke (C,0) 


N, + N,-1 


EXIT thru G 


Figure 4.2-3: NCS domain-return operation 


Figure 2. se 3. The added pcre use eh anforest oe us ied stack to 
revoke che! “appropriate capabilities from the calle before retriev- 
ing the Fetura gate and returning control | to the caller. Note that 


4 


the souneutica is total, and thus releases map entries in an orderly 


FE acs BP 


way, as discussed in Section 3. 7. 


4. 3 Directories 

The sovion of a dieser on: catalogue, or ‘ane-table mapping 
symbolic ebiect names into some form of internal object Dotnher 
has appeared in most “operating avatenss The idea of a large 
collection of directories arranged tn a tree-structured hierarchy 
originated nainly with the Multis syaton [Da 651, and has been 
adopted in several other systems ‘dace hat & time [st 73, i 72, 
‘RL 74], * 

. A davectocy consists pr a variable number of entries, each 
containing a a different symbolic name and a | pointer EG an object 
oe other antorestion to pe dtecussed shortly). "The seater ian 
that a unique directory entry is created with each object,” com- 
bined with the fact enet directories are thenselves objects, induces 
. tree-structured hierarchy on the set of all ‘objects in existence 
at ‘any tise. The internal aodee are the dtcastostes and cha leaves 
are the objects of other types. Concatenating the names of all 


entries along the path:from the root directory to a given object 


ahead the tree name oF that oe hopes uatnety: identifies it. 


zs ie 


The global tree-structured view of the universe of objects 


“Except the pre-defined "root" directory. 
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can be useful in several contexts, euch as aysten backup and 
“recovery, accounting, a as "described below, a solving the | 
“lost object problem," but it is often more convenient da other 
contexts to modify this view in two ways: | 

a) To allow the establishing of several dtrectory entries 
for the same object. 

b) .To allow general path names which | can ag Tarerpreted as 
starting in any amma rather then only the root- 
directory. —_ . 

Both of these features can be added bienedt ‘dieturbing the under- 
lying tree-structure, as long as the extra entries ("Links") in 
(a) can be distinguished from the original entries ("branches") 
when this is desired. This treatment: of Links as being full- 
fledged divesteey. ‘entries, ‘contrasts with the Multics approach 
in. which links are merely'a ve-neming Gexsce ane have. no pro- 
tection significance. We choose this 1 approach « to ‘facilitate sub- 
letting of reated objects. . 

| In addition to naning, the directory system ie useful for 
purposes of access control. Attaching an access list list to each 
directory entry aids in the orderly distribution of privileges 


to access shared objects. Each entry in the access ee contains 


a pair 
(lock, privileges) 


which allows any possessor of a Key saint. the pore to obtain 
the corresponding privileges.. (Of course, the epecdfication of 


the access list, like the creation and deletion of entries, 


RRR Ces hrc een rte kab 
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represents an access to the directory itself, and must also be 
controlled.) The simplest example of a lock would be a user name. 
A more sophisticated version of this is the "principle identifier" 
used in Multics [Sa 74], which is a kind of three-dimensional user 
name with more complicated rules for matching locks with keys. 

An even more flexible scheme will be described below. Note that 
in all such schemes, a user may not invent his own key(s), but 

may invent any locks he chooses and apply them to his objects, as 
discussed by Lampson [La 69]. 

In non-capability-based systems, directories are usually 
implemented as base-level objects [Or 72, Ri 74], since their 
access lists are generally used as the system's primary protection 
facility. In a ¢apability-based system, however, directories can 
be implemented as a higher-level extension, providing symbolically 
named "pigeon holes" for the storage and dissemination of capa- 
bilities [Fa 68]. This is an attractive organization, since it 
removes from the base-level system all handling of symbolic names 
and the corresponding variable-sized data structures. From the 
point of view of the base-level system, the directory layer is 
simply another user domain, although, of course, it must be regarded 
as a trusted machine extension by normal user programs which store 
their capabilities in directories. The desirability of providing 
both directories and capabilities in the same system is convincingly 
argued by Lampson [La 69]. 

The directory layer described below provides for storage of 
any number of capabilities in each directory, erie per entry. 


Attached to each entry is an access list authorizing a domain to 


146 


obtain a sealed copy of the stored capability by executing 
ge ae 
C + lookup (C,, Name, cy) 


where cy is a capability for the directory (authorizing lookup 
access), Hane isa character string, and i is a Ray capebility, 
The unique ID of the key capability is matched a4 against the locks | 
in the access list of the entry —_ the corresponding privileges 
are returned in C. Subsequent 1 reduction . eke privileges 
authorized to holders of key CG wil retroactively reduce the 
privileges in C, using the underlying revocation pachinery: 
(Various conditions, best! as faliure to find an entry with the 
giver name, Or failure to find a lock ia ‘che: access list watch 
matches the ‘key Cy cause errors to be signalled | and Ro ‘capability 
to be returned. > The use of freely distributable ‘capabilities as 
the keys authorizing directory zooriee allows the users to flexibly 
and econeetcanty establish any group authorization achene desired 
by simply paseing keys to each Onhar Neither ‘the base-level 
system nor the directory layer need take any explicit notice of 
such groups {ta 69, St 73). More complicated facilities such as 
path name lookup [Da 651, multiple directory searching [Or 72, St 73] 
and automatic lookup on first use of a symbolic name (Da 68) 

could be teclemsated in terms of "this basic lookup eens: 

these will not be discussed here. 


In such a directory system, there is ‘ho intrinsic distinction 


"Tn terms of base-level operations, this would be written 
C + call (C, ,C. Name, Cy) | | 


where isa capability for a gate into the directory layer 
correspoding to the lookup operation. 


between the various aETSCC OEY. entries containing eapabsieiae for 


a given object. For the reasons cited previously, OMENED it is 
aeENl to distinguish one of the entries ag a soraneh ang consider 
the others to be links. In particular, one can solve the lost 
object problem by guaranteeing that tie branch exiete for at least 
as long as the object. This is accomplished by creating the 
object and the branch simultaneously, and having the divecrory 
systen, upon removing the branch from ‘the directory, delete the 
object ‘(if it still exists). ae 
The use of branches to solve the lost ee lect peohien da rela- 
tively straightforward in the case Of basé-leval objects and | 
directories. By performing the creation oF all. each objects through 
calls on the directory layer which also create a directory branch, 
one can insure the existence of a branch for each new object. 
When the branch is ramied: the object can be destroyed by the 
directory layer, either internally ‘(in thé case of directories) or 
by calling the appropriate operation (4 the case’ of base-level 
objects). 
In the case of axtadided objects, however, the situation is 
more complicated, for two reasons: 
a) It is. inappropriate for the dizectoxy, layer. to have 
embedded in it any knowledge of. (e.g... calls on) higher 
layers. Ponts 3 wim var .ct ide 5) 
b) New higher devel. extended, Epes can, be Aptaned. at any 


wat 


time. es ae ee 5 ee fea pee 


PS td 


These considerations. render imposaible, the, ereation, of. such objects 


via the dtnectory layer, and  necongitate, at more. pirounapect 
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approach to their deletion when a branch is removed. 
When. a higher layer creates an exrended object X and wishes 
to take advantage of the directory system to pape x from becoming 


lost, it can do so by ‘executing 


make_branch (C,, Name, C,. C,) sf RE 


This State ud entry in the directory indicated by Cc): The 
entry has name Name and contains Cy» a capebility for the new 
object. In addition, the entry holds Cy; a capability for gate 
G into the caller (i.e. the layer implementing the object). When 
the branch is later removed from the directory, the directory sys- 


tem guarantees to execute 
call {C,;c,) a é- Ne 
The gate G should correspond to the deletion. cea for objects 
of the extended type, hence this. de equivalent to. 
delete (c,) : 
Of course, it is the responsibility of the lnyer itplementing xX 
to insure that this cali does fn fact result in the deletion of X. 


The directory layer's only concern is that it tsust be prepared for 


anything which may happen between the time it performs the call 


“Repeated use of the make branch operation specifying the same 
object X would cause the directory structure to'fail to be a 
tree, This might be of concern to layers at or #bove the level 
at which X was implemented (although it certainly would cause no 
‘trouble for the directory layer): ‘The layer tupiementing the ob- 
ject could protect itself from this situation if the smake_branch 
operation were modified to require an extra parayeter C;, a 
capability for the type of X, as authorization to make a branch 
for X. 
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and the time the callee returns. This could Ancluge various types 
of errors, bldcking of the process, and even further calls on the 

directory layer. The straightforvard way to “handle this is simply 
| to have the directory layer complete ite part St the ‘rgach removal 
and then exit to the ae deletion operation via: a jump-call as 
described in Section 2. 2." : = 

It mene appear that the calling of the higher layer object 

deletion operation by the directory layer vigtletes the ordering 
constraints of se labia eaten construction. | ‘This is not ‘Teally 
the case: however, since this call dos not represent any knowledge 
of the higner layer eubedied in the directory layer. Such "blind" 
Goward: calls are quite similar to hendaare “traps" or ‘Nexceptions:? 


The other directory layer operations of interest are; 


make_link (C,,Name,C,) 

remove entry (C,,Hame) 

set_lock (C,; Name ,L,P) 

Cc, + create_key aver 

beaatedivecters (C, Name) 

delete directory (C,) 
The make Hak operation establishes a new entry in directory D, 
containing c and nea Name, The reovee entry “operation 
removes a link or a branch. In the latter case, it performs 
object destruction as described above. The set; lock operation 


establishes a new lock on the awed entry in directory D. The 


lock is L (i.e. it can be opened using a key with capability-ID = L) 


We ignore the extra complications involved ‘if object « deletion is 
allowed to fail. 
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and it doatere the set of privileges P. The create key opexa~ 
tion simply returns a capability of type “hey! with a new unique 
capability-ID. The create _directory Seerat han establishes a new 
empty directory as a son of directory: D a. e. pointed to by a 

new branch in D with name Name). The delete directory opera- 
tion deletes the directory D. This requires removal of all 
entries from D, including any ‘branches for other directories 

| which must thus be deleted, and soon. In other words. the entire 
subtree rooted in D must be traversed and deleted. This compli-~ 
cation is best post poned until a higher level utility program, 
hence the directory layer can stuply refuse to delete a non~ 
empty directory. | 

The implementation of divedtorien as described is relatively 
straightforward. Each directory is represented asa segment, con- 
taining entries formatted as in Figure 4.3-1. ‘The original capa- 
bility C and the entry name are present when the entry is first 

created, along with the deletion~-gate capability in the case of a 
branch. Subsequent use of the set_lock Spatation prucseds as 
shown in Figure 4.3~2. Firet .the dock is added to the access list 
if not already present, together with a capabisity to hold cha” 

- privileges gorcesponding to ew lock. ‘This capability is created 
by sealing the original er, cy in a revoker box. Then 
the privileges in the capability are revoked down to the desired. 
level. Note that in the case of beviging the set; apek “operation 
to an already existing lock, any outstanding capabilities previously 
obtained via that lock using the Losi doatation will algo have 


their privileges revoked. Finally, if the nevoration was total 


spond the 2S A RRR te pies i Ra ast aoe 
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deletion gate capability* { 


“object capability { 


bee 


symbolic name 


= access list 


*in branches..only : 


Ptgure #.3+1: A directory entry 


¥ 
a 
z 


et = ae ea < Ser eS eee 
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set_lock(C, ,Name,1,,P) 


} 


“ENTER 


PI « thdex of . 
L in access list 


Cy + seal (CC ker 


Yes 


remove <Ly »C}> 
from access list 


‘Figure 4.3-2: The set_lock operation 
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fee: 


“a, e. P=0), the lock is deleted from the access list. (Such 
total revocation is Biso performed on each lock in the access list 
when the entire dtrectory ae. is removed. This is another exam- 
ple of orderly use of the underlying map machingry, “as discussed 
in- ‘Seétion Sopp cle ra hes ekeuoe Ake Bak ade BS . . 
“Phe lookup operation? upoti «Find fag the ‘nated “entty, ‘searches 

- the access list for a Yock datching thé pfoffered key: “If-one is 
‘found; “the cérrespording capabilfry “ts “eeated 4a“a lockdr box and 
returned ‘6 ‘the ‘calier.* trib pope aed reddt't “df the set ‘tock 
“and lookup operations ts distribution ‘of -calpattlities ‘following 
the didetprine“of Figure i P Po. Saree cae beige ie vinntibarts 

“fhe” Greate Key ‘operation is qutte @imple'to ‘Hmpheaieric It 
“would 'bé‘nteely captured by the dimple séaltrig’ of ‘an empty extender 
box. Lackiig this facility, ‘the directory ‘Udyer can atniply seal 
any’ ‘andy chpability, stnte: only thre * ‘external’ ‘gppearatice of the 
new "key. capabifity~is ‘signtficatit: m YEE baba Vidas 
" ‘Phe directory layer jist @dsdttbed ‘te prébably the best exam- 
ple of the ‘kind ‘of “uséful ‘exten#iotis ‘whitch “cat ‘be ‘éthidthicted using 
| the NCS ested § ‘capability méchiinien : ft provides “ettrémély useful 


features for ‘thé usd?s “of ‘the “é 


» yet ‘fts tapledentation is 
opendeved relatively “simple by ‘the "power UF thé “dadeFlying ‘Base- 
Level “namizig’ dnd protection factiitted! +124 6has > © ecace 
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Chapter 5 
“Summary and Conciusions 
5.1 Summary . _. 

This thesis has discussed initegeated naming and protection 
‘mechanisms for computer systems, providing protected aanes called 
_ capabilities which both identify an objert-and authorize access 
to it. A major sivantage of cenahl Sisiae de the flexibility pro-— 
vided by their being freely copyable. A. corceupond ing disadvantage 
in existing. capability systems bas been the. aistieuley. of revoking 
previously distributed capabilities. The main result af this 
thesis has. been the design of a capability s¥ysten providing both | 
free distribution and orderly revocation, of capabilities. Various 
approaches to this problem were discussed ja. Chapter. “2, culminating 
in a set.of goals to be met by a new design, The ‘generalized ie 
capability sealing mechanism of . Chapter 3 was. shown to,meet these 
goals, providing selective revocation af capabilities, as well as 
a flexible type extension facility, A posaible implementation of 
the design was discussed in sufficient metal: to demonstrate its 
practicality. Various possible elaborations, on. the design: were 
also discussed. Chapter 4 described, two facilities applying 
revocable capabilities to the meade of users, in specific. ways. 


5.2 An Area for Futther Research 


In terms of the facilities provided, the naming and protection 
mechanisms described in this thesis appear to be a sound basis — 


upon which to build a secure and flexible user environment. In 


particular, the Provision of revocable capabilities eliminates 


one of the main objections often made to capability-based designs 
[Se 72), thus making the proposed design applicable hea a wider 
class of ‘situations. One could thus characterize boies thrust of 
| this thesis as an Erect | on the Siexibility BBPeey of the pro- 
tection probles, . 

On the other hand, the thesis does not make any direct attack 
- on another more general aspect of the protection problem which one 
might call the comprehensibility of protection mechanisms. 
Experience indicates that protection mechanisms vhich are confusing 
to users are likely to be misused, or even go unused [Sa 74, Se 72). 
_ Even the uset who se Sale applies a ‘confusing pretection feature 
may Evel no great confidence er it enforces bis intentions. 
‘There are at least three ways in which protection systems can be 
confusing: _ 
| | a). They can pe paced: on a dtsorderly set of £ separate but 

interacting mechaniens. . 
b) ‘The relevance of the “mechantous to specific »: situations 


3 


can be obscure. 
et nao 


c) The correspondence between global state of the protection 
machinery and the desires of the users can be difficult 
to assess. aks . 

A fair amount of progress has een made on problem (a). The 

“early proliferation of ad hoc protection mechani nes was a major 

motivation for the originet Maeve lopment of capabilities (DVH 66], 

as well as pater more | abstract treatments by Lampson [La 71], 


Jones [Jo 73], and others. On the other hand, strict minimization 
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of the set of primitives will not necessarily clarity ‘the descrip- 


tion, ‘anpatiaily since it may ‘exacerbate ptoblem (b). For example, 


‘our unification of privilege revocation ‘and type extension in a 


single mechanism, while interesting in itself, “may ‘or. may not repre- 
sent a net increase in the couprehensibiiity of the design. 


Problem (b) is caused by the gap _ ‘often quite broad -- 


| between the concerns of the human users and the wechanisns provided 


by the protection system, in terms of which they must express 


those concerns. Of course, the weer’ feed not deal only: with the 


pxetedtion primitives of the system; various extensions, such as 


those mentioned in Chapter ee can be provided. These do not go far, 
however, in attempting to capture the iateyuntiona. between users 
geen in the larger social context. “This te due ia part to the 
imprecision of many legal and social principles, resulting from 
their implicit reliance on the reasonable Judgement of the parties 


| involved, a characteristic s andy decking in ‘most computers. Much 


work remains to be done in mapping ‘euch. principles into the pro- 
tection primitives of computer syetems {Ro i, Pe 14, Tu 74). 


Problem (c) is perhaps the moat “difficult of the three. 


During our discussion of capability mechantons, we ” emphasized 


the desirability of diloviag distribution and ‘revocation of capa- 


bilities without requiring set knowledge of such propagation on 


the 1 part of the participants. " Sueh ‘global. inowiddge is sometimes 


desirable for its own sake, however. ‘Moreover, ‘even if the entire, 


state of the protection wachinacy is visible (ahieh can ‘iteelf 


raise serious ‘questions ‘of privacy), the toll ‘significance of that 


state cannot ‘be eesaneed without inovledge of the levels of trust 


OSE EON OR EAST MIEN A TTT 
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and suspicion between the various possessors of access privileges. 
oe \ 
This appears to be a very fundamental problem, and it is not clear 


what approach (if any) will prove fruitful in dealing with it. 


5.3 The Future of Protection 
Much work remains to be done in the area of Prorecesops In 
the long run, protection will contribute to the dave lopaent of 
generally available computer utilities in at least three ways: 
| a) By facilitating the development of extremely large soft- 
ware systems, such as sophisticated service programs, 
and the operating systes: BE ithe computer utility itself. | 
b) By protecting the investments of users Naa sevelop large 
‘proprietary programs a foe date bases, dias providing a 
suitable marketplace for euch services, 
c) By enforcing Becta -coateols on the dissemination of 
ores information. 
- Given ne difficulty = importance of ‘the problems to be solved 
eeheaee ial promises to. be an active ates. of research for many 


years to come. 
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